LevelDB: A Fast Persistent Key-Value Store

Re:LevelDB: A Fast Persistent Key-Value Store by gojomo on Wednesday July 27, 2011 @04:36PM (#2813987)

An interesting development a while back that I'm surprised hasn't received more attention was Oracle's release of a SQLite-based interface to BDB:

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?

[ Parent | on HN ]

Re:LevelDB: A Fast Persistent Key-Value Store by gaborcselle on Wednesday July 27, 2011 @06:14PM (#2814459)

Thanks for the link! You could theoretically just compile this file against SQLite-based BDB: http://code.google.com/p/leveldb/source/browse/trunk/doc/ben... And get the numbers yourself. (If you do, please post them here.)

[ Parent | on HN ]

Re:LevelDB: A Fast Persistent Key-Value Store by est on Wednesday July 27, 2011 @11:25PM (#2815252)

> SQLite-based interface to BDB

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

    select * from users where name!='tom'

work ?

[ Parent | on HN ]

Re:LevelDB: A Fast Persistent Key-Value Store by gojomo on Thursday July 28, 2011 @03:00PM (#2818379)

You really don't know or care that you're using BDB; it works (to the user) just like SQLite. (Behind the scenes, it's using BDB for the tables/indexes, and so would do various full- or partial- table scans much like SQLite's native on-disk format.)

[ Parent | on HN ]