There are quite a few databases competing to be “king” of NoSQL. MongoDB claims to have the fastest-growing NoSQL database ecosystem, MarkLogic claims to be the only Enterprise NoSQL database, while other databases claim to be the fastest or most scalable system.
The creators of Redis rarely make any such claims. However, Redis is widely deployed and currently holds the highest ranking for a key-value store on the influential db-engines.com monthly ranking.
Redis (REmote DIctionary Server) was originally envisaged as a simple in-memory system capable of sustaining very high transaction rates on underpowered systems—such as virtual machine images.
Redis was created by Salvatore Sanfilippo in 2009. VMware hired Sanfilippo and sponsored Redis development in 2010. In 2013, Pivotal software—a big data spin-off from VMware’s parent company EMC—became the primary sponsor. Sanfilippo recently joined VC-funded Redis Labs, which provides Redis-as-a-service and commercial support for Redis.
Redis follows a familiar key-value store architecture in which keys point to objects. In Redis, objects consist mainly of strings and various types of collections of strings (lists, sorted lists, hash maps, etc.). Only primary key lookups are supported—Redis does not have a secondary indexing mechanism.
Although Redis was designed to hold all data in memory, it is possible for Redis to operate on datasets larger than available memory by using its Virtual Memory feature. When this is enabled, Redis will “swap” older key values out to a disk file. Should the keys be needed, they will be brought back into memory. This option obviously involves a significant performance overhead, since some key lookups will result in disk I/O.
Redis uses disk files for persistence:
- The Snapshot files store copies of the entire Redis system at a point in time. Snapshots can be created on demand and can also be configured to occur at scheduled intervals or after a threshold of writes has been reached. A snapshot also occurs when the server is shutdown.
- The Append Only File (AOF) keeps a journal of changes which can be used to “roll forward” the database from a snapshot in the event of a failure. Configuration options allow the user to configure writes to the AOF either after every operation, at 1-second intervals, or based on operating system determined flush intervals.
In addition, Redis supports asynchronous master-slave replication. If performance is very critical and some data loss acceptable, then a replica can be used as a backup database and the master configured with minimal disk-based persistence. However, there is no way to limit the amount of possible data loss—during high-load periods the slave may fall significantly behind the master.
Although Redis was designed from the ground up as an in-memory database system, applications may have to wait for I/O to complete under the following circumstances:
- If the Append Only File is configured to be written after every operation, then the application needs to wait for an I/O to complete before a modification will return control.
- If Redis virtual memory is configured, then the application may need to wait for a key to be “swapped in” to memory.
Redis is popular among developers as a simple, high-performance key-value store that performs well without expensive hardware. It lacks the sophistication of some other nonrelational systems such as MongoDB, but works well on systems in which the data will fit into main memory or as a caching layer in front of a disk-based database.
Redis (REmote DIctionary Server) was originally envisaged as a simple in-memory system capable of sustaining very high transaction rates on underpowered systems—such as virtual machine images.