3 ms·
It's interesting to have a non-LSM based persistent engine (If I read correctly). Although BTrees are slower when it comes to writing, they don't have compacti
by shin_lao 9y ago
It's interesting to have a non-LSM based persistent engine (If I read correctly).
Although BTrees are slower when it comes to writing, they don't have compaction issues and are generally better are reading data from disk.
I also like there is a lower-level API should you wish to build your own database logic on top of the block manager.
It would be interesting to have more information about how data is actually written to disk and I think such approach could benefit from being able to mount a device directly.
Last but not least, 255 GB will seriously limit this database to embedded use cases.
- adamansky 9y agoYes, b+trees are more performant for reading compared to skip-list because of better data locality on memory/disk. But SL better at insertion and sequential reads. 255 GB is a simple trade-off between disk space required per record and the ability to manage large data-sets since SL is a not very space friendly data structure) Although I think 255 GB is good enough in many use cases.