> I just looked, sophia is nothing special. See these microbench results. > http://pastebin.com/cFK1JsCN > > LMDB's codebase is still smaller and faster. Nothing else touches LMDB's > read > speed.
Focus to the write number. You are using SSD or HDD? On 11/4/13, Howard Chu <[email protected]> wrote: > Aris Setyawan wrote: >>> SQLightning replaces the SQLite backend with Symas' LMDB, which also >>> uses >>> MVCC >>> and thus supports high concurrency. It is also many times faster than >>> BerkeleyDB and vanilla SQLite. >> >> Your MVCC is different compared to InnoDB or BDB locking. Every one >> should carefully read each DB's doc, then test it before decide to use >> it. > > Yes, it's different. In LMDB writers never block readers and readers never > block writers. The original poster was complaining about SELECT taking a > long > time and preventing other threads from making progress. That problem doesn't > > exist in LMDB. BDB locking *might* be able to avoid this in many cases, if > there are no hotspots, but is prone to deadlocks which require the calling > application to retry failed requests. > >> LMDB is storage engine optimized for read. Why you don't optimize it's >> write using cache oblivious data structure, for example LSM tree or >> create new, like in sophia (sphia.org) key value DB? > > I just looked, sophia is nothing special. See these microbench results. > http://pastebin.com/cFK1JsCN > > LMDB's codebase is still smaller and faster. Nothing else touches LMDB's > read > speed. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
