Bug 2034605 - Switch to an SQLite storage backend#3405
Draft
Conversation
badboy
force-pushed
the
sqlite-2026-approach
branch
from
3a36fe1 to
f44b376
Compare
badboy
force-pushed
the
sqlite-2026-approach
branch
from
ad06137 to
eac4e8b
Compare
badboy
force-pushed
the
sqlite-2026-approach
branch
from
eac4e8b to
1a00a63
Compare
badboy
force-pushed
the
sqlite-2026-approach
branch
from
1a00a63 to
0dc1368
Compare
badboy
force-pushed
the
sqlite-2026-approach
branch
from
0dc1368 to
7396fb6
Compare
badboy
force-pushed
the
sqlite-2026-approach
branch
from
7396fb6 to
cee6d7a
Compare
badboy
changed the title
This is a modified version of the kvstore/skv implementation: https://searchfox.org/firefox-main/rev/cced10961b53e0d29e22e635404fec37728b2644/toolkit/components/kvstore/src/skv/connection.rs Which itself is based on application-service's sql-support. It's stripped down to what we need in Glean: * A file-backed database * A schema set up on start, potentially applying migrations if we need that * A read-write connection, which is re-used for all access.
This only integrates it into the module tree. It compiles, but not warning-free. It fully replaces the Rkv storage. No migration implemented.
The bincode crate isn't maintained anymore. While it's been stable and without issues for us for years, switching to anotherformat is easy while we're switching the database anyway. MessagePack can be even smaller than bincode for the same data (just a couple of bytes here and there). Whether it's actually faster has not been benchmarked. Compared to everything else the (de)serialization overhead is probably a small fraction of the whole thing. Why do we need serialization anyway? Ping assembly does not have any knowledge of metrics. It only knows what's in the database. So in order to put in in the right place in the ping payload we need to know the type of the stored data. That data needs to be somewhere. By serializing the whole value (the `Metric` enum) we can deserialize it into that enum and the serde part takes care of "knowing" the type.
badboy
force-pushed
the
sqlite-2026-approach
branch
4 times, most recently
from
bb6e1fd to
555b120
Compare
It's now easier to do: query the column and count. There's some complications when we get to dual-labeled metrics, but that comes later.
Now that it's just another column this becomes straight-forward to do.
Same way this was done on Rkv: we just some up the size of all files in the database directory.
This will unify label check code: all cases are handled through the same code paths, just that for the static label variant we don't need to do any more checks.
Basically anything that assumes the database layout of rkv, now that it has been reimplemented with sqlite.
…ater point downside: slightly worse error messages, but maybe we can inline them
This is another BREAKING CHANGE in the return type. We can't return references to the labels anymore, we need owned values.
…l moments See all details: https://sqlite.org/pragma.html#pragma_synchronous The default (FULL) syncs on every write. That's slightly higher guarantees, but also costly. We're already using WAL (write-ahead log). It's safe from corruption in NORMAL mode and consistent. It does lose durability, that means data might roll back following a power loss or system crash. Note: `rkv` does NOT sync at all. It only writes to disk (and moves files around). That's strictly worse than WAL in `NORMAL` mode.
badboy
force-pushed
the
sqlite-2026-approach
branch
from
555b120 to
b23fd65
Compare
It will be applied at start if (1) no sqlite database is detected, and (2) an Rkv database is detected. Migration works by iterating through all data in the rkv "safe-mode" database and inserting it into the new database. The Rkv database will be kept on disk. This will allow for a rollback if any problems are detected in production and we can implement a recovery step then.
These tests were disabled because they are very rkv-specific: Manually opening and writing to an Rkv database in the format that Glean expects. Then testing Glean behaves accordingly. We now do the same, but do it in SQL.
The previous refactoring duplicated some of the logic between different parts. Now we unify them again.
What individual tests do should be clear from their name or further comments inline.
This currently fails. The database is locked, so Glean can't access it. It's unclear how we should handle that. It's not a particular likely case to happen in practice.
The data was generated with
cargo run -p glean-tests --bin verify-data -- tmp
on an Rkv-powered Glean checkout.
The database (`tmp/db/data.safe.bin`) was then copied into glean-core/rlb/tests/rkv-database.safe.bin
badboy
force-pushed
the
sqlite-2026-approach
branch
from
b23fd65 to
7872360
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.