> The RocksDB engine developed by Facebook engineers is one of the fastest, most compact and write-optimized storage engines available.
Will it fix MongoDB's data loss issues? I'm hoping that is what "write-optimized" is partly implying.
Will it fix MongoDB's data loss issues? I'm hoping that is what "write-optimized" is partly implying.
It doesn't fix the election rollback issue, because that's handled way above the storage layer. It does solve a whole slew of storage engine related write issues though. No more "we flush to disk every 100ms and call it good".
"write-optimized" means they take great pains to turn all writes into sequential writes, to avoid random I/O seeks and get maximum I/O throughput to the storage device. Of course structuring data as they do makes their reads much slower.
LMDB is read-optimized, and foregoes major effort at those types of write optimizations because, quite frankly, rotating storage media is going the way of the magnetic tape drive. Solid state storage is ubiquitous, and storage seek time just isn't an issue any more.
(Literally and figuratively - HDDs are not going extinct; because of their capacity/$$ advantage they're still used for archival purposes. But everyone doing performance/latency-sensitive work has moved on to SSDs, Flash-based or otherwise.)
"compact" doesn't make much sense. There's nothing compact about the RocksDB codebase. Over 121,000 lines of source code https://www.openhub.net/p/rocksdb and over 20MB of object code. Compared to e.g. 7,000 lines of source for LMDB and 64KB of object code. https://www.openhub.net/p/MDB
I was under the impression that Rocks manages more compact storage, probably as another consequence of all those sequential writes being packed right next to each other, rather than LMDB's freelist-of-4k-pages model.
Is that the case or was I misreading whatever mailing list I got that from? Don't get me wrong, I value not having compactions more than slightly less write amplification, just checking my understanding here.