Database Benchmarking, II

While the keys I had for my first db benchmark were perfectly fine, most applications will see keys that are not that long. With that in mind, I decided to go the other way, test with short keys, 10.3 bytes long on average. For each key there’s a 40 bytes attached “value”.

I’ll repeat the tests in the previous post.

Insertions first.

	Pop. at start	Batch size	No. batches	Total keys	Sqlite time	nonblonde time
First run	0	65536	16	1048576	14.5s	3.8s
Second run	1048576	1	65536	65536	2.95s	2.2s

Again, allowing sqlite a large cache in the second run only hurt the speed. The number given is with no cache indication.

The file sizes.

	Sqlite file size	nonblonde file size
after first run, before reorganizing	88MB	287MB
before second run, after reorganizing	85MB	60MB

nonblonde space management is more liberal than that of Sqlite, as the former tries to consolidate (localize) writing while the latter is not bothered with scattered writing and is instead concerned with keeping tables sorted on disk and disk usage minimal. nonblonde is also meaning to preserve a number of recent past transactions on disk (in this test the transaction size was large — 64K keys). These combine into a larger database size on disk for nonblonde, though most of the taken space is just preserved past transactions. This space can be reclaimed by compacting the database. On the other hand, the Sqlite policy of keeping the tables/indexes in sort order on disk should see better (or lot better) subsequent scan and range query times.

And the query times.

Key count X Times	Sqlite	nonblonde
64K X 1	2.12s	.4s
1 X 64K	1.4s	.132s
diff	.72s	.268s