5 ms·
> LiteTree is more than TWICE AS FAST than normal SQLite on Linux and MacOSX!!! In my experience, claims like these usually end up showing that the author didn
by beardicus 8y ago
> LiteTree is more than TWICE AS FAST than normal SQLite on Linux and MacOSX!!!
In my experience, claims like these usually end up showing that the author didn't understand the `PRAGMA synchronous` setting at all, or they chose to ignore it to juice their stats.
In this benchmarking test are the data durability guarantees the same for both LiteTree and vanilla SQLite?
- coleifer 8y agoLooks like the speed comes from using lmdb rather than sqlites own storage layer.
- mschwaig 8y agoI first read this as IMDd for Internet Movie Database and got confused, but probably you mean LMDB for Lightning Memory-Mapped Database, which makes much more sense. :)
- JetSpiegel 8y agolmdb != Imdb Check your fonts if those two look the same.
- checker659 8y agoBut, AFAIK, lmdb is not write optimized (as opposed to something that uses LSM trees like levelDB).
- bluecarbuncle 8y agoI wonder if they got the inspiration from https://github.com/LMDB/sqlightning https://github.com/LMDB/sqlightning
- jrockway 8y agoI also read this sentence and my immediate thought was that I would only use three exclamation marks in the documentation for a database engine to say something like "TWICE AS MUCH test coverage!!!" If I want a fast database, I will just write my data to /dev/null. It has well-understood data durability guarantees and is very quick to write to.
- da_chicken 8y agoI prefer /dev/urandom or /dev/zero. They have a much higher likelihood of returning the data I wrote.
- jrockway 8y agoTrue! For maximum I/O efficiency, obviously you write to /dev/null and read from /dev/urandom.
- stuffchunk 8y agoJust how I like my CQRS!
- smolsky 8y agoNo, no, /dev/urandom is really slow...
- blattimwind 8y ago> In this benchmarking test are the data durability guarantees the same for both LiteTree and vanilla SQLite? Who cares if you get more bongoliomarks.