Database B-trees, II

In my previous post I have compared two database B-trees for in-memory insertions. That is, I have looked at the time it took the two B-trees to populate from zero, with no disk writing involved.

In this post I’ll be looking at the in-memory query time. All data is in memory, no disk reading is needed. The B-trees are the same from the previous post, the classical database B-tree (CDB) from LMDB and the nonblonde B-tree. LMDB wants the read operations to be in a transaction — all are in the same one.

LMDB is optimized for querying — or so its description claims. nonblonde isn’t. In truth, I don’t know what “optimized for querying” is supposed to mean for LMDB. I assume the design choices were skewed toward querying. nonblonde cares for editing just as it does for querying. One was not sacrificed for the other.

In this test I am querying all the keys present in the table/database, in random order (incidentally, the insertion order).

Key count	CDB	nonblonde
1048576	.776s	.574s
2097152	1.731s	1.415s
4194304	3.808s	3.054s

Key count	CDB	nonblonde
1048576	.877s	.609s
2097152	1.92s	1.365s
4194304	4.15s	3.075s

Key count	CDB	nonblonde
1048576	1.37s	.806s
2097152	3.2s	1.822s
4194304	7.05s	4.2s

For the last run, the LMDB database size on disk is 1,030,463,488 + 8,192 bytes (two files). The nonblonde database is 111,123,456 + 117,181 bytes (also two files).

The in-memory querying is where LMDB is supposed to shine. LMDB is the “lightning” database — the “lightning memory” database. LMDB is, according to the publisher, “extraordinarily fast”. It “has the read performance of a pure in-memory database.” Maybe not.