Hi there @Kido,
Regarding the performance of the two different ways of modelling your data ( using sorted sets or RedisTimeSeries ), and whether you should use sorted sets or RedisTimeSeries, it will always be bound to the complexity of your case, to how long you plan to store your data, and how you plan to query it. So to answer to wether Sorted Sets are faster or slower than RedisTimeseries, is it depends.
It’s will always be a trade off between ingestion (writes), query performance(reads) and flexibility (what you can do).
The RedisTimeSeries GA Blog post covers in depth both options ( and adds a few more ).
If you’re comparing RedisTimeSeries out of the box vs Sorted Sets, there are things you should take into account:
- WRITES: On the example above, you’re comparing uncompressed data ( sorted sets ) vs compressed one ( timeseries ). This is extremely important if you plan to keep large datasets. You should see a tremendous difference in the memory usage right away. Furthermore, insertion on sorted sets is O(log(N)), so it takes longer to insert, the larger the set becomes. Insertion on RedisTimeSeries is constant indepent on the number of datapoints you have on a series ( we’ve benchmark 800 Million datapoints with constant ingestion in following blog of RedisTimeseries 1.2 )
- READS: I believe that on the example above you’re querying in the simples manner possible via TS.GET correct? ( which is completly valid depending on the use case ). Notwistanding, if you plan to do aggregations over time (TS.RANGE), a common requirement on TSBDs use cases, you will need to either switch to a solution with the proper toolset for that ( example RedisTimeseries ) or do client side work. On reads is where you will notice a improvement on performance if you switch to RedisTimeSeries ( but again it depends on the use case ).
So, my educated gess is that there is no poor performance on the nodejs client, or either solutions. The answer to chose either sorted sets of redistimeseries will be strictly bound to your usecase, but on either ways you should be able to ingest in the order of millions of datapoints per second.
IMHO performance per-se should not be the ultimate decision factor but the proper toolset for the problem depending on how complex it is ( we should be able to get you to hit your performance requirements as soon as you’ve weighted other factors =) ).