Would the use of wired tiger as a storage engine affect these results?
Call Me Maybe: MongoDB Stale Reads
11–20 of 150 posts
Re: Call Me Maybe: MongoDB Stale Reads
#12Would the use of wired tiger as a storage engine affect these results?
My guess is no. This is more about the behavior of the database as a distributed system and not just a storage engine.
Re: Call Me Maybe: MongoDB Stale Reads
#13Would the use of wired tiger as a storage engine affect these results?
Definitely not
Re: Call Me Maybe: MongoDB Stale Reads
#14If you are a database author and you get a bug report from Kyle, spend a long time thinking about it before closing the issue as invalid.
For context (for those who didn't read the whole article): https://jira.mongodb.org/browse/SERVER-17975
Re: Call Me Maybe: MongoDB Stale Reads
#15The most interesting lessons from the Jepsen series: * You should never trust, and always verify, the claims made by database manufacturers. * Especially when those claims relate to data integrity. * Super-especially when every safety level provided by the manufacturer that includes the word "SAFE" is actually unsafe.
It seems easier to me to just go with a reputable database vendor.
Re: Call Me Maybe: MongoDB Stale Reads
#16People really underestimate the value of Occasional Consistency. Occasionally Consistent databases, like MongoDB, are great for approximation algorithms, sublinear time algorithms, and similar applications.
Re: Call Me Maybe: MongoDB Stale Reads
#17The most interesting lessons from the Jepsen series: * You should never trust, and always verify, the claims made by database manufacturers. * Especially when those claims relate to data integrity. * Super-especially when every safety level provided by the manufacturer that includes the word "SAFE" is actually unsafe.
It seems easier to me to just go with a reputable database vendor.
That island of safety is a rapidly shrinking one. Jepsen covers more ground with each new post from Kyle. :)
Re: Call Me Maybe: MongoDB Stale Reads
#18The most interesting lessons from the Jepsen series: * You should never trust, and always verify, the claims made by database manufacturers. * Especially when those claims relate to data integrity. * Super-especially when every safety level provided by the manufacturer that includes the word "SAFE" is actually unsafe.
Actually the broader lesson would be to assume the worst in your application layer and try and remediate/verify wherever possible. If you look at his articles: Redis, PostgreSQL, Cassandra, ElasticSearch etc all had data consistency errors. And none of those have vendors making any claims. It's pretty sobering to say the least.
Um, this is the postgres article:
https://aphyr.com/posts/282-call-me-maybe-postgres
There were no acknowledged writes lost. The only unacked-but-successful writes resulted from a connection while a commit ack was in-flight. That doesn't qualify as a data-consistency error, it means the client has to check if the data is present after reconnecting.
But in no cases would the client reconnect to find that there were acknowledged-as-committed records that were missing or stale. In no cases would the client find that responded-as-rolled-back data was actually committed. This is very, very different than what is seen with MongoDB.
Re: Call Me Maybe: MongoDB Stale Reads
#19upvoted for the Look Around You link alone.
[deleted]
Re: Call Me Maybe: MongoDB Stale Reads
#20I think it would be great to see one of these done for RethinkDB :)