

Alternative Memcache Usage: A Highly Scalable, Highly Available, In-Memory Shard Index - herewego
http://blog.maxindelicato.com/2009/01/alternative-memcache-usage-a-highly-scalable-highly-available-inmemory-shard-index.html

======
DenisM
Summary: _assuming that your lookup patterns can be answered with a hash
table, we can use scale-out hash table (memcached) in lieu of a database
index._

I am pessimistic. For one thing author did no address how he plans to keep
index fresh in the face of evictions or memcached nodes crashes. It gets
really bad - if you did not find the data, is it absent or has it been
evicted? Can you create a new user named "FOO" right now? You won't know until
you scan the whole data set, which is a "size of data" operation.

There is a case to be made for a resilient RAM-only distributed databases, but
using memcached is not it.

~~~
jrockway
Yeah, using a cache to store data you need to always have is a terrible idea.
I used to store session data in a volatile region like this (Cache::FastMmap,
if you care), until one day I realized that sessions were being deleted long
before they had expired. Oops, I was using a lossy store for data that must
never be lost. Now I use BerkeleyDB for that, and make sure that expired
sessions are manually cleaned up every so often.

~~~
DenisM
To be fair, idexes are redundant structures so data will not be lost
permanently in this case.

~~~
fhars
No, they will magically reappear the next time memcached is restarted. The way
the article describes the idea the same thing will happen when there is a
database error during user deletion: The user will be gone from the cache, but
may reappear later. To make this scheme work, both the database and memcached
must be made to support two phase commit, or the application must try to get
the shard information from the database if it isn't in the cache.

