This resource is a) data logged about Redis 1, previously my contact was a meetup b) notes on a module “timeseries” 2.

Basic Redis features

  • Data storage with namespaces 3
  • As everything is in RAM, its FAST! 4 5
  • As other NoSQL, Redis is designed for data structures 6 7. Redis architecture is that is not possible to make a generic very optimised system for large amounts of data; however providing tools to allow devs to optimise a structure to their requirements works 8.
  • Most of Redis is optimised for SELECT side, not INSERT side 9 10 11. It has a fairly even spread on execution time in this bench mark 12 (but this doesn't list any technique).
  • Redis doesn't implement your security model, you have to 13 14. It doesn't make sense to allow the internet to talk to your data store anyway...
  • Redis is a dictionary/ keystore structure, with Indexes 15 16 17 GIS 18 19 (compared to RRDtool, or sleepycat, being both is weird).
  • Redis uses types more strictly than other NoSQL systems e.g. 20. In particular, look at hashes as a means to store app Objects or Beans [Java speak] or documents [in Mongo speak].
  • Redis does support multiple “databases”, 21 although please observe this is in the same process, so there may not be any point. The same link states that the overhead from multiple Redis instances is small, and does horizontal scaling better.
  • Recent Redis has modules 22, which looks useful for embedding things 23. The most important one, IMO is “redisearch”, which supplies full text features 24 25.
  • Redis has few data manipulation features (according to 26, the entire API is ~480 commands), compared to platforms like Postgres; however it does support server side scripting via Lua 27. Lua scripting should be used cautiously, as it blocks the main thread in the DB 28, and secondly uses a single Lua interpreter instance for all scripting.
  • Redis does implement transactions, but in an idiosyncratic fashion 29 30 (the requirements are slightly different as it is single threaded; but uses modern IO kernel calls to multiplex the IO. Note IO is nearly always the prime limiting factor).
  • There are many references to lack of larger scale concurrency in Redis, due to its single thread. Redis is only atomic on certain operations, and has some issues with race conditions 31. The same can be said of many bits of software, but its less common on databases.

Some use cases

This section is basically pulling in marketing, so please read: 32 33 34 35.
As a note for MBAs, 36 37 Redis is a narrow target platform, and only suitable for some situations; but in those situations it is widely liked. The Wiki page lists some old stats 38, but I think these are too old for a main reference. I have a link, just for flavour, from the CTO of a Redis retailer 39

Timeseries variant

From here forwards, I abbreviate “Redis TimeSeries?” to RTS. Many of the systems I have built in the last 5 years involve “X against time” plots. Having a timeseries specific DB would reduce the amount of logic we need to implement these, so shortening timescales. Although not an area of attention on this article, the “timeseries best solution” discussed is to use a Btree, like file systems 40.
Some marketing for the RTS 41 variant 42 43 44 45.
It is worth doing this research, as RTS has a specific time type, which incorporates many useful attributes for data logging 46. It is hard to find references about the index. I suspect @antirez was thinking of physics simulations 47, when he labelled timestep. Do not confuse with TIME 48, which is just the Redis version of SYSDATE() 49 or CURRENT_TIMESTAMP 50.
I don't think the EXPIREAT command is specfic to RTS, but for continuous accumulation systems 51 looks useful.

The extension supplies the following commands 52 53

  • “TS.ALTER”
  • “TS.ADD”
  • “TS.MADD”
  • “TS.RANGE”
  • “TS.GET”
  • “TS.MGET”
  • “TS.INFO”

These are mostly quite intuitive action from their names.

Random links I haven't put into the txt yet:
Python access in a fairly readable fashion 54