http://www.oracle.com/technetwork/database/berkeleydb/overvi...

It's essentially drop-in compatible with SQLite, but with added concurrency and speed for most operations. (The concurrency addresses a major issue usually keeping SQLite as a prototyping/single-user-only option in web development.)

With LevelDB as a BSD-licensed alternative to BDB, I wonder:

(1) How would the LevelDB-vs-SQLite benchmarks change against SQLite+BDB backend?

(2) Could a SQLite fork with a LevelDB backend get a performance boost?

One thing I didn't get about SQL API for BDB, how does something like

    select * from users where name!='tom'

Previous discussion - http://news.ycombinator.com/item?id=2526032

Benchmarks vs Kyoto TreeDB and SQLite3 - http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html (discussion - http://news.ycombinator.com/item?id=2813061)

Benchmarks vs InnoDB - http://blog.basho.com/2011/07/01/Leveling-the-Field/

LevelDB is a persistence library.

That makes LevelDB the kind of thing you plug into membase to get the unique properties it has to offer (or at least for fun).

http://blog.basho.com/2011/07/01/Leveling-the-Field/

LevelDB sounds like something I would like to contribute to but if the reception is going to be chilly I won't bother, maybe pick up mongo or redis instead.

Is LevelDB batching writes or is there something more interesting going on?

And that is exactly what LevelDB is doing: writing a log (sequential), and when the memorychunk is full, it is writing it to disk sorted (this is also sequential).

Yes, updates can be done in one atomic batch. Please correct me if I'm wrong, but I don't think Tokyo Cabinet allows it without Tokyo Tyrant.

You turn off write-through caching on disks when you run a database unless you are willing to accept corruption (which is worse than data loss) on power outage. And that's why you can't get acceptable write performance out of database without a battery-backed RAID controller (or something other kind of RAM-based write cache with a battery backup).

Here's a simple way to test # fsyncs/s (a.k.a. commit rate) on your system:

  sysbench --test=fileio --file-fsync-freq=1 --file-num=1 \
   --file-total-size=16384 --file-test-mode=rndwr run --max-time=10 \
   | grep "Requests/sec"

Also, do you really mean turn off write-through, or did you mean write-behind? (I can't see how write-through would cause corruption, but maybe I'm missing something...)

Also, I wouldn't be surprised if there's a discrepancy in the flushing code across systems. God knows flushing a file to disk in cross-platform code is an arcane science :)

And finally, as somebody else pointed out, LevelDB seems to order write access sequentially as much as possible.

It's worth noting that the makefile includes options to build for iOS. I've successfully done it and my next iOS app will include LevelDB. Also worth noting, thanks to the iOS devices SSDs, it's much faster than with the traditional HDD machines.

Really excited about seeing IndexedDB run atop of this

That initial checkin: http://code.google.com/p/leveldb/source/detail?r=2

LevelDB is for if you need ordered data, and a more appropriate comparison would be against a B+\tree database.

LevelDB is slower with random reads, but that doesn't mean you shouldn't use it for unordered data - it's still quite fast.

In a positive analysis (should rather than shouldn't), assuming no default choice, it seems rational to use Tokyo Cabinet or CDB _hashmaps_ for unordered data, and LevelDB for ordered data, from a datastructure and performance standpoint. To assert more would probably need a specific use case for context.

It's as rational as doing optimizations. If the specific performance is extremely critical, yes, it definitely makes sense. But LevelDB does well with random reads [1]. With all its features and its permissive license, I think it's a strong contender as developer's go-to embedded key-value db, like SQLite for relational data.

Don't get me wrong, I do think your comparison is valuable, but I'm afraid it could be misleading; I specially found the wording LevelDB is for if you need ordered data misleading. Someone could read it and assume that LevelDB doesn't do well with unordered data.

[1] Compare today's benchmarks with these http://fallabs.com/tokyocabinet/benchmark.pdf, it looks like random reads in LevelDB are quite faster than BDB.

Other variables such as licensing are context dependent. In my context, I generally use embedded databases in shared library form to store arbitrary serialized Lua (much faster to reload than JSON, no need to compile protocol buffers) on my own servers, so in my development context LGPL vs BSD is irrelevant. But perhaps not for an iPhone developer. TokyoCabinet already has excellent bindings for nearly every language I've used, but thats irrelevant to a developer whose application is also C.

> Compare today's benchmarks with these http://fallabs.com/tokyocabinet/benchmark.pdf, it looks like random reads in LevelDB are quite faster than BDB.

I'd bet BDB is a snail, BUT the benchmark you just linked tests 0 databases in common with the one released by Google. What can be observed is that using a hashmap (TC) was over 7X faster than randomly accessing the fastest ordered data structure by the same author (TC-BT-RND) :)

[1] https://github.com/seppo0010/redislite

Downvoters: links to previous context are generally considered a good thing here.

Voldemort to LevelDB is what MySQL is to InnoDB: Voldemort is a distributed system that allows multiple engines to be plugged in. Mostly commonly, companies use either BerkeleyDB or MySQL as a storage engine. LinkedIn, Mendeley, EBay and others also use the read only storage engine, where the data is pre-built in Hadoop and loaded into Voldemort.

I am really excited about LevelDB: while there are higher priority projects on my plate right now, we'd very much like to see a LevelDB storage engine. If anyone is interested in contributing one, they're welcome.

The steps are:

1) Creating JNI bindings to LevelDB (or creating a .so version of LevelDB and creating JNA bindings)

2) Implementing the StorageEngine interface with the bindings, including passing in any configuration.

Here is an example of a third party InnoDB/Haildb storage engine for Voldemort:

https://github.com/sunnygleason/v-storage-haildb