[HN Gopher] Storage and transaction in mvSQLite, the distributed...
___________________________________________________________________
Storage and transaction in mvSQLite, the distributed SQLite on
FoundationDB
Author : losfair
Score : 42 points
Date : 2022-09-24 11:53 UTC (11 hours ago)
(HTM) web link (univalence.me)
(TXT) w3m dump (univalence.me)
| anacrolix wrote:
| Is it possible to do read replicas with this? Would that be a
| FoundationDB level concern?
| bastawhiz wrote:
| What's the use case for something like this? I'd think that
| instead of building a distributed version of SQLite on top of
| another database engine, you'd just choose a distributed database
| in the first place. Are there benefits to the way SQLite works
| that outweigh the choice to just use some other flavor of SQL?
| losfair wrote:
| The idea that mvSQLite is based on (decoupled storage and
| compute) has been implemented for the other two most popular
| SQL databases. MySQL and PostgreSQL have Aurora and AlloyDB,
| and PostgreSQL additionally has Neon. This is something missing
| from the SQLite ecosystem (before mvSQLite).
|
| And SQLite has a unique advantage when implemented on top of
| decoupled storage and compute. Decoupled MySQL and PostgreSQL
| can't really linearly scale from zero in a serverless use case:
| you need to spin up a compute instance when you want to do
| queries. This isn't necessary with mvSQLite, because the
| embedded SQLite library can just connect directly to the multi-
| tenant storage engine (mvstore).
| phamilton wrote:
| > This is something missing from the SQLite ecosystem (before
| mvSQLite)
|
| This is also something missing from self hosted, open source,
| SQL rdbms.
|
| As far as I'm aware, this is the closest thing to Aurora and
| AlloyDB that I can run myself.
|
| Also, by leveraging FoundationDBs ability to have multi-
| writer deployments, it gives us the potential to scale writes
| far beyond what Aurora and AlloyDB can handle. I'd love to
| see an extreme benchmark comparing a single 24xlarge Aurora
| writer vs a few dozen nodes in FoundationDB. The Aurora
| writer is likely more efficient per CPU but ultimately can't
| scale past 96 cpus.
| [deleted]
| [deleted]
| endisneigh wrote:
| The article mentions it not being bug-free, what are some of the
| bugs?
| losfair wrote:
| Software that is not formally verified _contains_ bugs.
|
| All known correctness bugs are fixed (except experimental
| features) - this is just a reminder that you need more than one
| layers of defense for something that stores your critical data.
___________________________________________________________________
(page generated 2022-09-24 23:01 UTC)