[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Against sqlite3!!!
From: |
Arthur Miller |
Subject: |
Re: Against sqlite3!!! |
Date: |
Tue, 07 Dec 2021 19:43:30 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Qiantan Hong <qhong@mit.edu> writes:
>> That would be quite a
>> disadvantage compared to a DB approach where I'd naturally expect that
>> only the value I'm asking for is loaded.
Sqlite does not read one key per request, it reads at least a page. So if your
system uses 64k pages, sqlite will read at least 64k at once. Then you also have
system doing disk i/o, caching nodes and so on; so you are never really getting
just "the value you are asking for to be loaded".
> It does, but I’ve done some benchmark and it loads 10k entries in 0.02~0.03
> seconds. 100k entries takes <0.5s.
> I’d say it should be suffice for most Emacs application I know of.
> Nobody is using Emacs for trillions of business records.
>
> On the other hand save operation is fully incremental and don’t
> even need to be invoked explicitly.
>
> Being said that, if we really find out loading is not fast enough, I might
> come up with some way to load it in segments lazily. I doubt if that will
> ever become necessary.
>
>> Also, how would it ensure consistency when I have 2 parallel emacs
>> sessions (like one for mail/irc and one for programming/editing) where
>> session 1 modifies the value of key A and the other of key B? It looks
>> like the values of the kv-store that gets saved later will win. In case
>> that's the emacs session which has modified B, it'll revert A to the
>> state before the other session modified it, no?
> Since it records a log of deltas instead of printing the whole data structure,
> different key won’t interfere.
>
> Being said that, currently it probably won’t work because UNIX append
> is not atomic and will probably be interleaved into nonsense.
> There’re various workarounds, lock file being one, but I like
> the idea of keeping only one “controller” instance with exclusive
> access to the file more.
You can do same as sqlite does: just lock entire file (db). Sqlite locks entire
db while writes are performed. It can be configured to allow concurrent reads
but only if there are no ongoing writes.
Re: Against sqlite3!!! (Was: sqlite3), Zhu Zihao, 2021/12/07