4 ms·
Are there any scenarios where you would want eventual consistency over strong consistency? (Assuming pricing, performance, replication etc are the same.)
by howlgarnish 6y ago
Are there any scenarios where you would want eventual consistency over strong consistency? (Assuming pricing, performance, replication etc are the same.)
- crazyjncsu 6y agoNo.
- nhumrich 6y agoAt the benefit of added availability? absolutely. This is the entire premise of mongodb.
- nullsense 6y agoMongoDB is webscale.
- castlecrasher2 6y agoI want the one with the bigger GBs.
- nullsense 6y agoBetter yet, just pipe all your data to /dev/null it supports sharding. Sharding is the secret in the webscale sauce.
- oblio 6y agoAvailability? I thought Mongo was fast and scalable, I don't remember anyone recommending it for higher availability.
- nhumrich 6y ago> Fast and scalable > Availability These are synonyms. How do you scale? Horizontally. How you do it without degrading performance, is the same way you increase availability. Eventual consistency.
- TheCoelacanth 6y agoJob security?
- dboreham 6y agoTrain tunnels
- acdha 6y agoYour last sentence is the answer I’ve always heard given: this in the context of a performance trade off — do you wait for every node in the system to acknowledge an update and purge caches, or return as soon as a sufficient durability threshold has been hit?
- robotresearcher 6y agoNo. A magical do-everything datastore would have strong consistency. Eventual consistency is something you might settle for given the performance cost trade offs. To see this, consider that strong consistency has all the guarantees of eventual consistency, plus some more. And the additional guarantees might make your application much easier to write.