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.
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?
Because read optimization is what was important to us when I created LMDB.
That's like asking why a hammer isn't a screwdriver.
On 11/3/13, Howard Chu <h...@symas.com> wrote:
Aris Setyawan wrote:
SQLite do not use row level locking, but db level locking, so it was
the right behavior the second thread was blocked.
For innodb like in SQLite, Oracle have SQLite compatible API, but use
BDB backend.
Since BDB use MVCC (row/page level locking), your threads only blocked
if they will write in the same row/page.
www.oracle.com/technetwork/database/berkeleydb/bdb-sqlite-comparison-wp-176431.pdf
* You must aware that BDB now have AGPL license.
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.
https://gitorious.org/mdb/sqlightning/
On 11/3/13, Raheel Gupta <raheel...@gmail.com> wrote:
Hi,
I have been using SQLite for one project of mine and I will be storing
TBs
of Data.
Now there will be a lot of selections in this database and I have come
across one problem with SQLite.
In journal_mode=delete the selection is database locked.
When one thread does a "TRANSACTION" on the database and soon after
another
thread does "SELECT" on the database (using the same connection) or vice
versa, the second thread has to wait till the first thread finishes.
In order to avoid this, I had to use journal_mode=wal so that two
threads
dont have to wait when they both are doing SELECTs which might be taking
3-5 seconds to process.
I was wondering if Row Level Locking would be introduced in
journal_mode=delete as its there in InnoDB for MySQL. Atleast for
selects
or inserts Row Level rocking should be possible as neither modify the
existing rows.
journal_mode=wal is a little slower and has its own limitations over
NFS.
OR if there is a mode equivalent to innodb in SQLITE please do let me
know.
I need to do a lot of selects and inserts in my application and hence a
row
level locking is suitable vs table or database level locking.
--
-- 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
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
