There are a lot of new database systems popping up that can be interpreted by the newbie as “memcache, but with persistence”: MemcacheDB, Membase, redis, Project Voldemort etc. I’ve seen the term “persistent Memcache” being thrown around a lot, which is an oxymoron in itself, as the term “persistent” undermines the implied ephemeral nature of a “memory cache”. We must be careful not to mislead those impressionable by buzzwords into adopting the wrong technology for the wrong uses.
It’s not uncommon to hear the comparison “like a persistent version of memcache” being thrown about, and it is understandable why it is used. While brave new ground is being covered by these new DBMs, this simile acts as a straightforward introduction to these new technologies and how they work. If you’ve worked with web development or MySQL for any tangible amount of time, chances are you’ve had experience with Memcache and its simple key/value data model. So it’s a great technique to help tame these wild and mysterious new technologies so that we understand them better in terms of what we already know.
However, we must be careful not to let this comparison transcend the fundamental differences between these systems. I fear that many regard “persistent Memcache” as a drop-in replacement for the original Memcache so that they don’t need to worry about cache timeouts or its ephemeral nature. Whereas the important distinction to make here is that these systems are databases, and Memcache is a cache, and nothing else. For best performance, it is important that both are still used in a way that complements their design and intended usage. I am worried this likeness will foster poor data model design, as developers feel more secure with interchangeably using their caches as databases, and vice versa, adopting the wrong technologies and software design paradigms on this premise. Sure, many of these “NoSQL” persistent databases can be used as a cache, but to engineers building high performance systems, it is important to keep the distinction in mind to avoid unnecessary overheads.
