4 ms·
Luckily for CRDTs, consensus-based strong consistency doesn't work well for most applications in geo-replicated scenarios, so CRDTs are kind of inevitable there
by zzzcpan 8y ago
Luckily for CRDTs, consensus-based strong consistency doesn't work well for most applications in geo-replicated scenarios, so CRDTs are kind of inevitable there. And they are still new and cutting edge, still need time. Look at the history of Riak, we wouldn't even use the same designs today as they did just a few years ago.
- lumost 8y agoUltimately though it's pretty straightforward to write an accurate merge function for most distributed applications with the pro that you can think about them in a locally strong consistent manner. While I could see a better ORM style auto-merge system existing I don't see the hassle of CRDTs being worthwhile when the vast majority of geo-replicated systems have extremely small numbers of record level write conflicts across Geo's. I'd venture that the number of potential write conflicts introduced by FB users hopping geo's is small enough to simply report an error to the client and forcing a retry - or handled by a hand-shake before the customer crosses GEOs Is there any practical database application where a CRDT is useful?
- manigandham 8y agoThe practical application would be the example I posted about Redis replication. Any application complex enough to need geo-replication is also likely not just writing a single key per user. There will be shared keys and data structures like tables/lists/hashes that all need to be synced.
- mping 8y agoCorrect me if I am wrong, but don't FaunaDB and CockroachDb implement strong consistency? I don't think they use CRDTs but maybe I'm wrong. I'm just a curious guy, by any means an expert