4 ms·
500 inserts is way too small for a database benchmark. At that size point you're stressing the in-memory format of the database and not the actual IO performanc
by hendzen 11y ago
500 inserts is way too small for a database benchmark. At that size point you're stressing the in-memory format of the database and not the actual IO performance. I'm guessing LevelDB just wins because it's considerably simpler and doesn't have to go through a schema layer - it's literally just a LSM tree.
- maxpert 11y agoI tried it with 5K to 10K entries and it still out performs SQLite or any other engines. For SQLite the default and most probabilistic way a programmer will implement a key value store. You can try the sample on your own machine as well.
- hendzen 11y agoWell, you're also doing a random insert. That workload will always perform better on an LSM tree when compared to a B/B+ Tree (used by the non-LevelDB engines). Can you post sequential read/write benchmarks in addition?
- maxpert 11y agoI the article I have already covered that LevelDB is known to have better sequential performance anywayz http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html
- pvg 11y agoDo you mean 'likely'? Because 'probabilistic' is something else.
- maxpert 11y agoI would say likely