On Fri, Jul 29, 2011 at 8:53 AM, Richard Hipp <d...@sqlite.org> wrote:
> On Thu, Jul 28, 2011 at 12:27 AM, <res...@googlemail.com> wrote: > > > they used > > > > CREATE TABLE test (key blob, value blob, PRIMARY KEY(key)) > > CREATE INDEX keyindex ON test (key) > > > > Notice the inefficiencies inherent in this schema. > > (1) A primary key on a BLOB? Really? > (2) They create an redundant index on the primary key. They would double > the write performance with no impact on read performance simply be omitting > the index. > > I propose a new set of benchmarks, SQLite vs. LevelDB, with the following > schema: > > CREATE TABLE test(key INTEGER PRIMARY KEY, value BLOB); > > I'm thinking SQLite will do much better in that case, and may well exceed > the performance of LevelDB in most cases. (This is a guess - I have not > actually tried it.) > > Of course, if you really do need a blob-to-blob mapping, then I suppose > LevelDB might be a better choice. But not many applications do that kind > of > thing. What SQL database (other than SQLite) even allows an index or > primary key on a blob??? Actually as per their blog-post ( http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html ) . They probably want to simulate "an ordered mapping from string keys to string values" and to test "batch updates that modify many keys scattered across a large key space". _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
