ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Redis Virtual Memory

A couple of days before 2009 ended, Salvatore Sanfilippo ( @antirez) has announced his intention to implement virtual memory in Redis. In his message to the Redis user group, he has also mentioned some of the goals or advantages of virtual memory in Redis:

  1. If the dataset access pattern is not random, but there is a bias towards a subset of keys (let’s call this subset of keys the “hot spot”), with VM Redis can deliver performance similar to the case where you have in memory only the hot spot, using only the memory required to hold the hot spot.
  2. Your hotspot is much bigger than your RAM, but you are willing to pay a performance penalty because you want to use Redis.

Today, Salvatore has reported that the first phase of implementing virtual memory in Redis was completed and the Redis Twitter-clone app is already running on this new version.

According to the initial plan, the first phase is a blocking implementation VM.

This means that Redis will work as usually, but will have a new layer to access keys that will be able to understand if a key is in memory or swapped out on disk: when Redis tries to access an on-disk key, it will block to load the key from disk to memory (this includes not only I/O, but also CPU time needed to convert the serialized object into the memory representation).

Right now it is not yet decided if this is just an intermediary step before implementing a non blocking VM or it will become part of a release.

While I am neither a concurrency nor a Redis expert, I must confess that my previous experience with a similar solution to Redis single threaded approach was disappointing — I am referring to the Jackrabbit, the Apache JCR implementation where we had to circumvent the serialized single threaded access for read only clients. On the other hand, there are other well known systems (f.e. memcached) which are using the same solution (some will point out that as opposed to Redis, memcached is never touching the disk, while Jackrabbit has a behavior much closer to Redis).

Anyway, we will always have around these Redis benchmarks for sanity checks.