If it's based on Raft, then it sacrifices availability if there aren't a quorum of nodes online.
If it's based on Raft, then it sacrifices availability if there aren't a quorum of nodes online.
And yeah, you kind of have to sacrifice availability if you want to stay consistent in the face of write skew...
And logical address space is still far in excess of what most disks or arrays can fit, right? 40 bits or so on linux?
EDIT: 47 bits, for 128TB -- http://stackoverflow.com/questions/2159456/whats-the-max-fil...
If Moore's law holds, a single SSD will outgrow the address space in around 7 years. In four years, an array of eight disks would outgrow the address space. This is just for a single server. If you want a linearly-scaling, robust solution for future requirements (like multi-petabyte and exabyte distributed datastores), there's no reason to lock yourself into technology that'll be obsolete in half a decade.
(edit: SanDisk says it may release 8TB SSDs next year, also adding "We see reaching the 4TB mark as really just the beginning and expect to continue doubling the capacity every year or two, far outpacing the growth for traditional HDDs")
This makes sense for the current generation of storage sub-systems, though it would be misleading to say using memory map technology will be "obsolete in half a decade". The 48 bit limit is arbitrary. Manufacturers have 56 bit designs on the table right now, and there is nothing stopping them from implementing full 64 bit virtual address support.
As far as the address space and big SSDs thing.. I'd be willing to gamble on linux supporting mmap up to the biggest devices on the market, one way or another. Heck, there's only 16 more bits after that 47 before every FS under VFS has to be rewritten, right?
The author of LMDB makes pretty bold performance claims and people are too eager to believe them.
You shouldn't propagate those claims unless you've done benchmarking to verify them.
The author of LMDB doesn't really make bold claims, he actually just included LMDB (and the venerable Berkeley DB) in LevelDB's published benchmarks. The benchmarks were developed by the LevelDB team.