Posted by: Sasirekha R
cache, Key/Value Pair, KVP, NoSQL, Redis, Replication
Redis, NoSQL with extensive features – Part II
Redis supports master-slave replication that can be used to improve scalability – multiple slaves to scale to huge amounts of reads, as well as for improved data redundancy.
Redis allows any number of slave servers to be exact copies of master servers. The important facts about Redis replication are:
- Slaves are able to accept other slaves connections. It is possible to connect some of the slaves to other slaves in a graph-alike structure.
- Redis replication is non-blocking on the master side, implying that the master will continue to serve queries while one or more slaves are performing the first synchronization.
- Replication is blocking on the slave side, implying that while the slave is performing the first synchronization it can’t reply to queries.
- Slaves are able to reconnect to the master when the master-slave link goes down and comes up
In order to start the replication, the slave connects to the master and issues the SYNC command. The master starts a background saving, and once completed transfers the file to the slave. If the master receives multiple concurrent slave synchronization requests a single background saving is performed in order to serve all of them. The master also sends all the new commands that had the effect of a dataset modification, to the slave(s), as a stream of commands.
Redis provides Transactional support. A Redis transaction is entered using the MULTI command which always replies with OK. Then the user can issue multiple commands. Instead of executing these commands, Redis will “queue” them. All the commands are executed once EXEC is called. Calling DISCARD instead will flush the transaction queue and will exit the transaction.
A Redis Transaction allows the execution of a group of Redis commands in a single step, with two important guarantees:
- All the commands in a transaction are serialized and executed sequentially. It can never happen that a request issued by another client is served in the middle of the execution of a Redis transaction. This guarantees that the commands are executed as a single atomic operation.
- Either all of the commands or none are processed as the EXEC command triggers the execution of all the commands in the transaction.
The Multi/Exec (M/E) process is designed to prevent syntax errors during execution by immediately reporting syntax errors whenever a command is added to the queue. MULTI returns an “array” of replies, where every element is the reply of a single command in the transaction, in the same order the commands were queued.
M/E does not provide complete ‘transactions’ – since it does not include ‘rollback’ functionality. If there is a relatively large M/E queue (say with 100 commands) and EXEC command is triggered and the server fails after processing 65 commands. These 65 are executed and the rest are not. So in effect, M/E is only an “all or nothing” before the EXEC command is run (i.e., during the queuing) and not during the execution.
To solve this issue, in the upcoming version of Redis, the commands in the queue would only be written to the AOF upon successful completion of the EXEC command. So if the server crashes mid-EXEC, the state can be rebuilt according to the previous, pre-EXEC state.
Other points on Redis
- Redis is currently sponsored by VMWare.
- Salvatore Sanfilippo, the creator of Redis, is a strong proponent of a ‘zero-configuration’ install philosophy. Redis has no hard dependencies and it is found that it takes 34 seconds to go from “download to server interaction”.
- Redis is currently in use at Boxcar, Craigslist, Dark Curse, Engine Yard, Github, The Guardian, LLOOGG, OKNOtizie (the biggest Italian social news site), Ruby Minds, Superfeedr, Vidiowiki, Virgilio Film and Wish Internet Consulting.
- List of use cases: http://www.paperplanes.de/2010/2/16/a_collection_of_redis_use_cases.html.
Redis is pretty fast giving performance of 110000 SETs/second, 81000 GETs/second in an entry level Linux box. It handles writes even faster than reads. The performance is mainly because Redis keeps the entire dataset in memory and only periodically syncing to disk. The user has various options of improving durability by trading off on performance.
Redis offers so many features (http://rediscookbook.org/) and is substantially different to the other NoSQL brand products.