Hacker News Reader

Comment by hinkley | Hacker News Reader

I still maintain that the existence of in memory databases has two main sources: scalability bottlenecks in GC, and storage latency falling behind network latency and staying there.

If general purpose programming languages could store the data efficiently in main memory, the feature set of in memory databases is not so high that you can’t roll your own incrementally. But your GC times are going to go nuts, and you’ll go off the rails.

If the speed of light governed data access, you’d collect your data locally and let the operating system decide which hot paths to keep in memory versus storage.

The last time network was faster than disk was the 1980’s, and we got things like process migration systems (Sprite). Those evaporated once the pendulum swung back.

View on HN

It depends on what is meant by in-memory database. The most useful kind IMO is the one which actually saves everything to disk, but is not designed like a traditional RDMS in that it assumes everything, including indices, can be saved in memory. Therefore, you don't need a complicated buffer pool system and you don't need to touch disk at all after startup to service read queries. The most simple approach to such a database is just to MMAP a file.

This kind of workload is probably the most common in all of software development for the past couple of decades given how plentiful RAM is as well as most applications having some need for storing persistent data.

I always feel a little weird using memcached because it has never once crashed on us but when it goes down we have a bad time with circuit breakers.

We only have problems with memcached when we create them ourselves. Disk backing store would soften that considerably.

memcached type API with RocksDB backing store is pretty good. Honestly, at this point hasn't every one written some in memory DB with various methods to persist and various consistency models as a result? At this point the magic is in client routing to the appropriate shard without having to redeploy to change the shard configuration and to allow multi-remote callers to access the data and still get access without disk load or mutex/locking around the data.

I have a thing where the shards each have sub-shards in process and 1 go-routine per sub shard; communication to/from the remote callers is via channels to a per-request go-routine (or whatever it is gRPC does) and the main subs hard go-routine has no locking on itself. Just a big hash map and a DLL to implement an LRU so I have a hard cap on memory usage, and no allocations for lookups or mutations (just creations).

Since you mentioned MMAP: "Are You Sure You Want to Use MMAP in Your Database Management System?" https://www.cidrdb.org/cidr2022/papers/p13-crotty.pdf

Dataset was 20x times larger than available RAM in that case, so it makes sense that OS cashing was useless and only induced overhead..

Another potential issue was that they compared their mmap code to fio O_DIRECT code, which kinda not clean experiment, fio could be just much more optimized itself..

Besides this point, I mostly mentioned it as an example of probably the simplest in-memory yet disk-backed database imaginable. For example, if you want to implement any sort of transactions, you don't want to actually do anything like fsync until you start trying to commit the data.

It's also worth while reading the rebuttal from ravendb: https://ayende.com/blog/196161-C/re-are-you-sure-you-want-to...

Also worth mentioning LMDB, probably the fastest embedded K/V db in terms of read perf uses mmap.

I suspect John Ousterhout https://web.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf would have other ideas.

Reply on news.ycombinator.com