atomicdata-dev
Sqlite storage
Related Issues
closes #443
Checklist
- [x] Add changelog entry linking to issue, describe API changes
- [x] Add or update tests if needed
- [ ] Update docs if needed
After experimenting with open dal, my conclusion is that the best replacement for sledge is SQLite in WAL mode. This is an implementation of it, including a connection pool which will take care of multi-node deployment. With SQLite instead of sled an Atomic server can be deployed on top of Turso or Cloudflare durable objects which will minimise infrastructure management - and allow standard backup and recovery tools. On the dev side, we can remove Tantivy and make a multi-criteria collection - the issue with export/import is a tantivy lock.
Hey Alex! Thanks for this :)
I must admit I never really considered using SQLite as a KV store - wasn't even aware they had it!
My big question is probably: how does it compared to sled? I'm OK with paying some minor performance price, and some binary size price, to have the stability of SQLite, but how much?
Mozilla did a benchmark on KV stores and found SQLite to have pretty bad performance, as in orders of magnitude slower than LMDB. Sequential reads (which AtomicServer does on every atom, for every commit!) are about 200 times slower.
I'm not sure what this would mean for real-world performance impact, but my hypothesis is that if we populate Atomic with a realistic set of resources and watched queries, the commit time will skyrocket.
Two things: you can store trie in SQLite, not only KV and second- original benchmarks only add few milliseconds to add_resource with all resources fetched under 20 ms. I didn't run benchmarks on dedicated hardware, worth re-running.
I have benchmarks locally, my local branch has further improvements than the current PR I will create a new one shortly.
This is the current development of all_resources()
This is new with all_resources() sqlite backend and removed tantivy: