3 ms·
LMDB claimed speed and reliability seems remarkable (from a quick glance). I would guess is easier to achieve such, for a KV store, than for much more complex R
by garyclarke27 8y ago
LMDB claimed speed and reliability seems remarkable (from a quick glance). I would guess is easier to achieve such, for a KV store, than for much more complex Relational Database. Got me thinking though.
Mayby Postgres could take advantage of LMDB?
Mayby by using LMDB as it’s cache? instead of using OS page cache, maybe writing the WAL to LMDB?
- lmb 8y agoLMDB is not a great fit for something like the WAL, where new data is written at the end, and old data discarded at the start. It leads to fragmentation (especially if WAL entries are larger than a single page).
- ddorian43 8y agoMaybe with https://github.com/kellabyte/rewind https://github.com/kellabyte/rewind which should support WAL for lmdb
- hyc_symas 8y agoLMDB itself only uses the OS page cache. The way for LMDB to improve an RDBMS is for it to replace the existing row and index store, and eliminate any WAL. This is what SQLightning does with SQLite. Have looked at replacing InnoDB in MySQL, but that code is a lot harder to read, so it's been slow going. Postgres doesn't have a modular storage interface, so it would be even uglier to overhaul.
- garyclarke27 8y agoThanks, make sense, I think Postgres are planning go have pluggable storage interface in nest version 12, would that help? Also nobody has mention data checksum added v9.3, do you know if this helps avoid this kind of fsync related corruption?
- anarazel 8y ago> Also nobody has mention data checksum added v9.3, do you know if this helps avoid this kind of fsync related corruption? Not really, I think. Page-level checksums don't protect against entire writes going missing, unfortunately.