4 ms·
For some write-intensive applications it is faster than everything else. E.g. http://symas.com/mdb/hyperdex/ http://symas.com/mdb/hyperdex/ Depends a lot on yo
by hyc_symas 12y ago
For some write-intensive applications it is faster than everything else. E.g. http://symas.com/mdb/hyperdex/ http://symas.com/mdb/hyperdex/
Depends a lot on your key and value sizes - the larger the values, the faster LMDB is vs any other solution, due to the zero-copy behavior.
- lafar6502 12y ago_wmd, hyc_symas I understand the principles of LMDB operation, the worst case scenario is lots of random writes that hit random pages in the db file. In such case the I/O will be heavy and random also, which leads to bad performance of disk operations (not so bad with SSD ,though). But you're right, if you avoid the worst case LMDB shines.
- hyc_symas 12y agoI'm pretty sure the worst case is purely size-dependent. The write pattern in the HyperDex benchmark is pure random but it still obliterates HyperLevelDB (and don't even think of vanilla LevelDB there). Keep in mind that LMDB uses free pages in sorted order, so even for a random write workload, pages are allocated in ascending order, which generally translates to unidirectional seeks on an HDD. This is why even for a purely random write load, LMDB is still faster than all of the traditional update-in-place B-trees out there - they really have to do random seeks, LMDB doesn't. (And you pay the highest in seek time when the drive head has to reverse direction.) That's why LMDB write performance remains uniform under load, while all LSMs suffer from GC/compaction pauses. But ultimately, storage is moving to solid state, and seek time will be irrelevant.