[Date Prev][Date Next]
RE: back-bdb future
At 06:07 AM 3/16/2003, Howard Chu wrote:
>> -----Original Message-----
>> From: Jonghyuk Choi [mailto:firstname.lastname@example.org]
>> >At one point Kurt mentioned exploring using BDB itself for the cache,
>> using a
>> >memory-only database. Has anyone looked into this? I wonder what the
>> >semantics are for such a database in a transaction
>> environment, since it
>> >no persistent store.
>> BDB cache's gain over database page cache may not be large.
>> In addition to the normal DB access overhead, transaction
>> subsystem adds
>> 3~7% of excess overhead even for non-transaction protected searches.
>> so... entry cache would still be considered as a higher perf store.
>> - Jong
>My wording may not have been too clear. I am not talking about using a
>memory-only BDB database to store entries in a disk-datbase-style format. I
>mean using the memory-only database to store the pointers to the cached
>entries, instead of using libavl. The question is whether a hashing scheme,
>or a Btree scheme, might be more efficient than an AVL tree.
On nice thing about using BDB here is that they provide a
common API for both Btree and Hash structures.
>However, your point about DB overhead probably still stands.
In back-bdb, that overhead will likely have to be increased due
to read transactions. The only way I can see to resolve the
read deadlock problems otherwise would be to ensure backend
is never reading and writing at the same time.