Re:Building a Distributed Log from Scratch, Part 1: Storage ...
by rakoo on Saturday December 23, 2017 @07:40AM
(#15993965)
If you're interested in those, there are at least two other designs you should have a look at:
- couchdb uses a single file for each db, which means the write ahead log _is_ the storage. The atomicity is guaranteed by saying that the latest root is the valid root. If writes are interrupted, everything since the last root is invalid and discarded upon restart. A simple design that just works, although it tends to be wasteful and requires frequent compactions
- lmdb (https://en.m.wikipedia.org/wiki/Lightning_Memory-Mapped_Data...) uses copy on write to make sure space is properly used, and atomicity is provided by sharing only the strict minimal pieces of information, so small in fact atomicity is guaranteed by the os. Follow the different links in the wikipedia page, there's a lot of interesting stuff
- couchdb uses a single file for each db, which means the write ahead log _is_ the storage. The atomicity is guaranteed by saying that the latest root is the valid root. If writes are interrupted, everything since the last root is invalid and discarded upon restart. A simple design that just works, although it tends to be wasteful and requires frequent compactions
- lmdb (https://en.m.wikipedia.org/wiki/Lightning_Memory-Mapped_Data...) uses copy on write to make sure space is properly used, and atomicity is provided by sharing only the strict minimal pieces of information, so small in fact atomicity is guaranteed by the os. Follow the different links in the wikipedia page, there's a lot of interesting stuff