On 11/24/2016 10:41 PM, Howard Chu wrote:
Florian Weimer wrote:
On 11/24/2016 02:54 PM, Richard Hipp wrote:
On 11/24/16, Florian Weimer <fwei...@redhat.com> wrote:
I'd like to replace the use of Berkeley DB in RPM with SQLite.
The scenario is special in the follow way. There is no database
server,
all access goes directly to the database. Unprivileged users without
write access to the RPM database are expected to run read-only queries
against the database. Privileged users (basically, root) is
expected to
use locking to exclude concurrent writers. But read-only users should
not be able to stop acquisition of a write lock.
Is there a way to do this with SQLite?
Seems like quite a lot of burden to go this route. SQLite has a much
larger footprint than BDB, and much worse performance overall.
SQLite has zero footprint for us because central parts of the system use
it as well, and it is not likely to go away. We also use the full
Transaction Data Store, so the Berkeley DB shared object is about twice
as large as the SQLite object.
As a
compromise you could use SQLightning, which replaces SQLite's Btree
layer with LMDB. Since LMDB *does* allow readers that don't block
writers.
How does it do that? Does LMDB perform lock-free optimistic reads and
retroactively verifies that the entire read operation was consistent?
The web page currently says that “readers need write access to locks and
lock file”:
<http://lmdb.tech/doc/>
The restriction on opening the database twice within the same process is
something which we would have to work around, too.
I see you are working on eliminating the key size limit, which is nice.
Thanks,
Florian
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
