Comments on: Performance comparison: key/value stores for language model counts

By: Holger

Holger — Sat, 16 Feb 2013 16:56:54 +0000

Hello, i have been using BerkleyDB for more then five Years to store Key / Value Pairs for my Searchengine at http://www.amidalla.de. The Client is in Perl and i dont see many Performance Differences in setting the Cache Environment !? Maybe this is just Perl specific, i did not test this with the C++ Client.

By: Samona

Samona — Tue, 11 Oct 2011 16:35:33 +0000

Ciao, trovo questo sito fortemente per nulla male. Grazie mille per le idee. bye

By: Pranas

Pranas — Sat, 06 Mar 2010 02:49:34 +0000

I completely agree with Bob. It makes no sense comparing mapping implementations if you need something different ;-).
Still it is nice what you share your observations.

Thanks

By: Performance comparison: key/value stores for language model counts › ec2base

Sun, 17 Jan 2010 10:40:39 +0000

[...] http://anyall.org/blog/2009/04/performance-comparison-keyvalue-stores-for-language-model-counts/ [...]

By: brendano

brendano — Sat, 28 Nov 2009 04:21:01 +0000

By: jd

jd — Wed, 04 Nov 2009 23:40:54 +0000

@Evil Bob,
msync() to sync to the filesystem and fsync() to sync to disk?

By: Chris

Chris — Mon, 26 Oct 2009 18:00:18 +0000

Thanks a lot for this writeup. We’ve got some large berkeley DB files and we’re looking into migrate to tokyocabinet for performance reasons. Your post was certainly useful.

We have found pretty huge differences with the BSDDB cache size, and we’ve done tons of performance tweaking. I’m definitely looking forward to checking out how hard it is to port to TokyoCabinet, and how much time we can save.

By: Shane K Johnson » Blog Archive » How I learned to say ‘No’ to SQL

Wed, 30 Sep 2009 14:24:22 +0000

[...] Performance comparison: key/value stores for language model counts [...]

By: Tim

Tim — Wed, 12 Aug 2009 03:27:32 +0000

FYI, I’ve also made a performance test for Redis, Tokyo Tyrant and MemcacheDB.
(request per second)
http://timyang.net/data/mcdb-tt-redis/

By: Evil Bob

Evil Bob — Wed, 24 Jun 2009 00:53:46 +0000

Tokyo Cabinet only occasionally flushes to disk because it memory maps the database file and as a result synchronisation is controlled by the kernel’s virtual memory manager.

The advantages of this approach is that you no longer need manage the synchronisation and you gain extra performance since your program no longer needs to make fsync system calls. The disadvantage, as some of you have pointed out, is that you can no longer control the synchronisation and if you don’t agree with the virtual memory manager’s synchronisation algorithm, you’re stuck.