Comments on: A tale about key value databases.

By: Architecture for a Deduplicated Archival Store: Part 2 | The Pseudo Random Bit Bucket

Sat, 15 Jun 2013 18:31:44 +0000

[…] A Tale about key value databases. Share this:LinkedInFacebookDiggTwitterTumblrLike this:Like Loading… This entry was posted in Storage, Technical and tagged backup, Computer data storage, Data Compression, Data deduplication, Storage on June 15, 2013 by moinakg. […]

By: john

john — Thu, 15 Nov 2012 21:39:10 +0000

Those numbers are surprising. Would you post code? GDBM should be more than twice as fast as Tokyo/Kyoto for reads, yet really slow for writes. GDBM is famous for this trade-off.

By: Viet

Viet — Tue, 21 Feb 2012 22:36:21 +0000

Hi. Thank you for analysis. I’m considering HamsterDB as a replacement for SQLite as I hust need speed and reliability, without schema. Would you please share the test code? Thank you.

By: Smokeless Cigarette

Smokeless Cigarette — Wed, 01 Dec 2010 06:31:06 +0000

I disagree with the overall premise of this page but I still think its pretty useful. I really like your writing style. Keep up the great work.

By: Martin K.

Martin K. — Tue, 26 Oct 2010 11:41:31 +0000

These guys accomplished 750,000 qps on a commodity server by writing a MySQL plugin that speaks NoSQL:
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html

For lessfs, Embedded InnoDB might even be enough:
http://www.innodb.com/products/embedded-innodb/

By: John

John — Tue, 05 Oct 2010 19:39:29 +0000

I’m concerned that your testing does not take disk i/o into consideration — especially in the case of TC without HDBOTSYNC. In 0.376 sec, I doubt TC has yet written anything to disk. In the real-word use of lessfs, once TC begins to commit to disk, performance drops horribly.

I think that how many records can be inserted over a sustained period of time would be far more interesting than timing a sort burst of records. Sustained throughput to multiple databases, potentially all using the same block device, would be closer to the use case of lessfs.

By: Szycha

Szycha — Mon, 27 Sep 2010 08:46:08 +0000

Will you be switching from TC to anything else (e.g. Hamsterdb)?

Thanks for your work, as usual.

By: jors

jors — Sun, 19 Sep 2010 18:06:22 +0000

@Adam: Same as said manu regarding Firebird: it is a SQL database and not a key value database.

By: Sean Leyne

Sean Leyne — Mon, 30 Aug 2010 23:44:57 +0000

It seems that there is an instrict trade-off. Performance vs. resiliency.

Given the nature of an FS, it would seem that resiliency is what matters most.

As for performance, assuming that your database statements will be prepared, the performance should be very good. I must admin that I have never been too concerned about the performance on an individual/simple insert/update/select statement for my application needs.

By: Adam

Adam — Sun, 29 Aug 2010 20:08:43 +0000

What about sqlite?
http://www.sqlite.org/