LevelDB: A Fast Persistent Key-Value Store
Wednesday, July 27, 2011 | 10:00 AM
Labels: c++, leveldb, library, storage
LevelDB is a fast key-value storage engine written at Google that provides an ordered mapping from string keys to string values. We are pleased to announce that we are open sourcing LevelDB under a BSD-style license.
LevelDB is a C++ library that can be used in many contexts. For example, LevelDB may be used by a web browser to store a cache of recently accessed web pages, or by an operating system to store the list of installed packages and package dependencies, or by an application to store user preference settings. We designed LevelDB to also be useful as a building block for higher-level storage systems. Upcoming versions of the Chrome browser include an implementation of the IndexedDB HTML5 API that is built on top of LevelDB. Google's Bigtable manages millions of tablets where the contents of a particular tablet are represented by a precursor to LevelDB. The Riak distributed database has added support for using LevelDB for its per-node storage.
We structured LevelDB to have very few dependencies and it can be easily ported to new systems; it has already been ported to a variety of Unix based systems, Mac OS X, Windows, and Android.
LevelDB has good performance across a wide variety of workloads; we have put together a benchmark comparing its performance to SQLite and Kyoto Cabinet. The Riak team has compared LevelDB’s performance to InnoDB. A significant difference from similar systems like SQLite and Kyoto Cabinet is that LevelDB is optimized for batch updates that modify many keys scattered across a large key space. This is an important requirement for efficiently updating an inverted index that does not fit in memory.
LevelDB is available on Google Code, we hope you’ll find it useful for your projects.
By Jeff Dean and Sanjay Ghemawat; Google Fellows

23 comments:
Ambarish Malpani said...
Hi Jeff, Sanjay, do you also have a Java version?
July 27, 2011 10:21 AM
Angelyx said...
@Ambarish - You can easily write some java overlays using C in native code blocks =D
July 27, 2011 12:02 PM
Alec said...
Does this store data directly to disk like a traditional database or does it work in memory like redis.io? What are the potential advantages/disadvantages of LevelDB compared to something like redis?
July 27, 2011 12:23 PM
Ben said...
I'm a big fan of this work. In fact, we're using a lot of the concepts here to redesign compaction in Apache Cassandra[1].
https://issues.apache.org/jira/browse/CASSANDRA-1608
July 27, 2011 2:59 PM
Dubas said...
How LevelDB compare to redis?
July 27, 2011 3:37 PM
Dubas said...
How LevelDB compare to redis?
July 27, 2011 3:37 PM
Josiah Carlson said...
Section 2, part A of http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html has strange data/graphs for the Random Writes part.
LevelDB looks to be a great addition to the key/value store world.
July 27, 2011 10:14 PM
MaXPert said...
@Dubas doing that would be unfair and it wont make sense ( you are actually trying to compare an apple with a banana ), I had one such argument once ( I replied to it too you can check it out http://maxpert.tumblr.com/post/4530634931/yet-nosql-dogma if you want ); but I think Google has done a great job; hopefull somebody will pretty soon write a network interface to LevelDB ( Volunteers anyone? )
July 27, 2011 10:23 PM
Steak and Martini Liberal said...
Any evaluation done on its latency?
July 28, 2011 9:42 AM
Samat said...
As a library-level key-value store, am I wrong in thinking LevelDB is a competitor to BerkeleyDB? LevelDB would be a nice alternative — BDB's non-portable, architecture-specific databases can be a PITA.
Are there any benchmarks comparing the two?
July 28, 2011 5:10 PM
Samat said...
As a library-level key-value store, am I wrong in thinking LevelDB is a competitor to BerkeleyDB? LevelDB would be a nice alternative — BDB's non-portable, architecture-specific databases can be a PITA.
Are there any benchmarks comparing the two?
July 28, 2011 5:11 PM
James Mansion said...
Interesting - but I'm concerned by those synchronous write numbers. Did the host have any sort of RAID with BBU? If not, then any numbers you get that suggest more than 1 write per revolution of the platters are indicating that the operating system is a poor database host.
For 7k2 drives, that means you should top out at 120 max, and often lower if the directory metadata is being updated.
How can leveldb claim to do so many independently persisted synchronous writes?
It looks awfully like there is a write-behind in operation.
(Has to be said: getting Lnux to write through disk caches etc is somewhat tricky. What are the relative numbers like on, say, ZFS or NTFS, where disk cache flushes seem to be more predictable?)
July 29, 2011 1:12 AM
rvt said...
I agree with Samat, I don't see a really value in comparing LevelDB with sqlite. It's like comparing Apple and coca cola bottles.
What I didn't read here, or may be I missed it. Does LevelDB have a sql interface to access data?
If so, I would be very interested in it's join performance between various tables and select data from..
July 29, 2011 6:18 AM
electroniceel said...
Hi, does LevelDB provide easy support for hierarchical storage? E.g. lookup one key and the value is another key/value table. You lookup by key in that and get another key/value table - and so on.
July 29, 2011 10:39 AM
Paul Harrison said...
Nice. Almost fast enough.
Needs a way to write an update (eg add to existing value) without having to read the value.
July 29, 2011 3:55 PM
Rajesh Koilpillai said...
@rvt The limitations section of the LevelDB project page, mentions that there are no SQL interfaces to access data.
July 31, 2011 9:09 PM
MaXPert said...
I did some benchmarks: http://maxpert.tumblr.com/post/8330476086/leveldb-vs-kyoto-cabinet-my-findings
Why are my results different?
August 4, 2011 12:53 AM
Ashwin Jayaprakash said...
I hope somebody implements a fast Java wrapper. (Hint hint) http://code.google.com/p/jnaerator/ is probably a good place to start.
August 4, 2011 8:47 PM
niu tech said...
How good is LevelDB comparing to Berkeley DB, Redis, Riak or Membase?
August 6, 2011 6:09 AM
James Phillips said...
@niu tech: re: Membase/Riak/etc. versus LevelDB - really different animals. As was noted at the very top there, Riak has evaluated LevelDB and we're doing the same @ Membase. You can think of LevelDB as a key-value storage engine, while Membase (now Couchbase) is a clustered document database that could use something like LevelDB underneath.
August 29, 2011 4:10 PM
Dude From Mangalore said...
How does it perform compared to CouchDb?
August 30, 2011 12:12 AM
Harsha said...
Hi All,
I have a product which currently uses Berkley, now we are planning to replace the berkley db with the leveldb.
I am trying to compile the LevelDB code using visual studio 2010 and facing lot of issues.
If anybody has already done this then please let me know.
Thanks,
Harsha
September 6, 2011 1:09 PM
A Industry Spoiled Software Engineer said...
I was able to compile and test leveldb successfully by doing some minor changes.
I am currently looking for a comparison table between Berkley DB and LevelDB. Need to know more about it.
Would highly appreciate any help on this.
Thanks,
Harsha
September 7, 2011 11:49 AM
Post a Comment