RedisTimeSeries
RedisTimeSeries copied to clipboard
RedisTimeSeries
Added support for binary data
The RedisTimeSeries API is cool, but makes a strong presumption on the fact that the timestamped data is of type double, that allows simple maths on aggregation functions. All the rest of the API (range queries, labelling, downsampling, rules ... ) is of interest for non-scalar data. This commit adds support for binary data. In can coexist with scalar data, so that the API remains 100% compatible. Just like scalar time series, binary time series can be created with 'TS.CREATE' or 'TS.ADD', just by adding the 'BLOB' keyword in the command.
Aggregation is supported but obviously, performing maths on blob is nonsense, so that only aggregation types of 'count', 'first' and 'last' are allowed.
Persistence on disk is also supported.
The testsuite has been completed with the test of the new features, and passes 100%
Signed-off-by: Thierry Bultel [email protected]
Hi despite of all my attempts, I cannot reproduce the valgrind failure on my side, even when I am using the debian-buster container.
This is the way I launch the test:
make test TEST=test_ts_blob:test_blob VALGRIND=1
Am I missing something ? Thanks !
Hi, all tests completed with OK status. Is this Ok for that PR to be merged ? Thanks !
Hi @tbultel, Sorry for the long wait. We are not sure yet if and how we see this feature in RedisTimeSeries. Can you explain why this is more useful for you than using redis streams?
Hi @danni-m, There are several reasons why it is of interest to have the feature in RedisTimeSeries:
- leverage the Duplicate policies
- from user applications, have a single an unified API to store/retrieve data
- same timestamping / labelling mechanism
- leverage some aggregation
To illustrate with a real world use case of us, let's take the example of collecting data from a big passenger boat, with many and various sensors. Most of the time, 'float' of 'integer' data is enough. But there are some other special case, where upon an alarm, a short sample of sound, for instance, or a screen shot, or a picture, could be acquired. Another identified case is when sensors with some close IP report opaque data.
Hope this helps ! Thierry
Sorry, closed it by mistake. @Danni, would you mind having a look on it ? It is now months I rebase it, about once a week. Thanks !
@tbultel This is a really cool feature; if such functionality exists, the number of keys I need could be reduced by several orders of magnitude.
