3 ms·

Thanks for this. I really feel like I understand the algorithm, and more importantly, the tradeoffs involved, after reading that. My company makes a product t

Thanks for this. I really feel like I understand the algorithm, and more importantly, the tradeoffs involved, after reading that. My company makes a product that involves a sort of primary feature that's insanely read heavy (something like 10k to 1 read to write ratio), and a secondary feature that's exactly the opposite. We just use Postgres with for both (and it's obviously the winner for the read heavy workload) but I think I'll have to look more into this stuff. One interesting thing to note about our write heavy workload is that the reads are usually in chronological order, with a filter. Anyone know what that implies for LSM based stores?

cpitman 10y ago
If reads are chronological, a simple journal is both simpler and faster. See Kafka for an example of this in practice.
biokoda 10y ago
> insanely read heavy Then LMDB is the engine for you
thesz 10y ago
Tune LSM merging algorithm parameter. If LSM merges levels at the 1:10 ration and more, then the result will be less levels and faster reads. The merges will happen quite often relatively to reads. If it merges levels at the ratio of 1:1.0001, then there will be more levels and less merges - less delays in write-heavy application.