Bug 2034605 - Switch to an SQLite storage backend#3504
Merged
Conversation
badboy
force-pushed
the
main-sqlite
branch
4 times, most recently
from
13689af to
899269d
Compare
Member
Author
|
/run-ios |
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.
Now that it's just another column this becomes straight-forward to do.
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.
Same way this was done on Rkv: we just some up the size of all files in the database directory.
Member
Author
|
/run-ios |
chutten
approved these changes
Jun 19, 2026
chutten
left a comment
chutten
left a comment
Contributor
There was a problem hiding this comment.
r+wc
Possible later augmentation: on filesystem errors creating the db, go in-memory (https://sqlite.org/inmemorydb.html) so we're still able to report the failure.
Member
Author
|
…f silently dropping errors
…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.
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.
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.
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. migrate rename
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.
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
The previous refactoring duplicated some of the logic between different parts. Now we unify them again.
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
2 participants
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.
This is essentially #3405 but from the branch we've been slowly merging into:
main <- main-sqlite.
This is what will finally get merged.
It won't need a full review again, all indidivual pieces have been reviewed previously.This branch is rebased against
mainto ensure we do not lose any commits frommain.