There’s been a recent rise in interest in “in-memory databases”. The reasoning given is that the cost of synching commits to disk is high, and this is the bottleneck in write operations; ACID databases require that a commit is confirmed written to disk – which often actually requires two or more disk writes, each with a seek penalty of a few milliseconds. Therefore, on-disk databases struggle to commit more than a few hundred updates per second, unless you invest in very expensively large RAID stripe sets.
Reads aren’t an issue, as every disk-based database does caching
in memory. If your database is large enough to fit in memory, or
access to it is mainly concentrated on a subset that’s small
enough to fit in memory, reads are just as fast as any in-memory
database. It’s writes that are the issue, and an in-memory
database can update records very
quickly indeed.
However, in-memory databases suffer a downside: …
[Read more]