Keep everything in memory in the usual sort of data structures (e.g. hash tables). Save changes to disk, but never read from disk except at startup.
It's a form of the Command design pattern and has some nice properties. You can get transparent thread synchronization by executing queries in parallel but serializing commands that modify state. For web apps, the HTTP request offers a natural representation for commands (but of course you'd want to strip them down to their essence). You can get fault-tolerance and scalability by feeding the command stream to replica servers. (State-changing commands must be executed by the master server but queries can be load-balanced across the replicas.) And if you keep the journals around, you have a complete history of the application's state.
EDIT: See also http://www.advogato.org/article/398.html
And appending data to a log is essentially an ideal disk access pattern.
Of course this can't be said for the snapshots, but you can offload that task to a replica server.
it's often also used as an LRU cache on top of a normal database so that you can still get the benefits of persistence and rich queries but use memcached to lower the number of hits to the disk/DB.
Also when you use memchached as a db cache, be preprared to lose some transactional properies of the database storage.
"When you have the users on your server, you don't have to rely on benchmarks, for example. Benchmarks are simulated users. With server-based software, you can watch actual users. To decide what to optimize, just log into a server and see what's consuming all the CPU. And you know when to stop optimizing too: we eventually got the Viaweb editor to the point where it was memory-bound rather than CPU-bound, and since there was nothing we could do to decrease the size of users' data (well, nothing easy), we knew we might as well stop there."
Couldn't you have done better if, instead of keeping all hash entries in memory, you kept them on disk and used memory as an LRU buffer? It seems like you could have fit more users on a server that way.
It's snappy and with very little overhead.
LOL keep downmodding me. I'd love to see the hashmap-based transaction handling. Was it as good as this:
No one says that if you need a relational database you should reimplement it yourself - just that the DB is not the only solution for all web back ends.
Most problems I've worked on had to take scaling, concurrency, searching/lookup, report generation (joining), etc, into account...all of which a dbms gives you out of the box. Maybe we're dealing with _very_ different kinds of problems.
The problem was completely parallelizable; stores didn't interact.