6 ms·
Assuming it works the same way as their MySQL product, Vitess: The usual way to run it is that you partition your db based on something like a user, so that si
by mcpherrinm 6d ago
Assuming it works the same way as their MySQL product, Vitess:
The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be.
I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)
- ronfriedhaber 6d agoTherefore, Consistency guarantees are based on implementing application-specific partitioning (correctly)?
- mcpherrinm 6d agoYeah. Vitess does have some options for atomic cross-shard commits using an additional database to track two-phase commits, but that's expensive so you probably want to avoid that. https://vitess.io/docs/25.0/reference/features/distributed-transaction/ https://vitess.io/docs/25.0/reference/features/distributed-t...
- osalberger 5d agoThe consistency guarentee assuming repeatable read or higher on each shard is parallel snapshot isolation, which is technically still higher than postgres read committed. If you have serializable on each shard and you chop transactions so you have no cross shard transactions, the application is technically still serializable, it just behaves like two independent deployments of the application for different shards