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??? I hereby call on all you loyal readers out there to help me come up with a more balanced comparison between SQLite and LevelDB. The published benchmark from Google strikes me more as a hit piece than a reasonable comparison between the databases. I'm on a business trip and am unable to help a great deal until early next week. So your cooperation will be greatly appreciated. May I suggest the following comparisons as a start: (1) Rerun the Google benchmarks with (a) WAL enabled and (b) the redundant index removed. (2) Modify the Google benchmarks to test an INTEGER->BLOB mapping using an INTEGER PRIMARY KEY on SQLite, instead of the BLOB->BLOB mapping. I suspect that I will come up with other suggestions once I have a chance to dig a little deeper into the benchmarks. If you have suggestions, please publish them here. Thanks for your help and support! > > > on random replaces it doubles the write operations. > > > > J Decker schrieb: > > On Wed, Jul 27, 2011 at 6:22 PM, Stephan Wehner <stephanweh...@gmail.com> > wrote: > >> There are some benchmark's at > >> http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html > >> > >> I don't have anything to point to, but I thought sqlite3 does better > >> than stated there. > >> > >> In particular, 26,900 sequential writes per second and 420 random writes > >> per second from section "1. Baseline Performance" look suspicious. > >> > > > > Wow, that's a bad mark for sqlite; I dunno it's somewhat misleading, > > because I do know that if I use sqlite as a logging database, and > > stream data to it it's kinda slow, and works better if I bunch up > > inserts with multiple value sets. But, enabling transactions, and > > doing the same thing, write speed goes way up. And now with WAL > > journal, it might affect that speed test also in auto transact mode > > especially > > > >> What you say? > >> > >> Stephan > >> _______________________________________________ > >> sqlite-users mailing list > >> sqlite-users@sqlite.org > >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > >> > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
