@Howard I had tested your code earlier but it didnt seem to be stable and
getting it to run was a task. Also I learnt that it is a "in-memory"
database.

@Aris are you saying BDB is better and faster than SQLite ?


On Sun, Nov 3, 2013 at 8:28 PM, Howard Chu <h...@symas.com> 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.
>>
>> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to