Maybe we should listen to Larry Ellison when he say "gimme my money!"
Call Me Maybe: MongoDB Stale Reads
21–30 of 150 posts
Re: Call Me Maybe: MongoDB Stale Reads
#22Earlier quoted context omitted.
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. :)
Has there been any CP system passing a call-me-maybe test first time apart from Zookeeper [1]?
Re: Call Me Maybe: MongoDB Stale Reads
#23Question: How do I actually run Kyle's tests to see this for myself? (Not that I don't believe him, I just want to play around a bit.)
When I run `lein install` and then `lein test`, I get:
╰─▶ ψ lein test
Exception in thread "main" java.io.FileNotFoundException:
Could not locate jepsen/db__init.class or jepsen/db.clj on classpath: ,
compiling:(mongodb/core.clj:1:1)
at clojure.lang.Compiler.load(Compiler.java:7142)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)Re: Call Me Maybe: MongoDB Stale Reads
#24I think it would be great to see one of these done for RethinkDB :)
RethinkDB engineer here. RethinkDB currently doesn't support automatic failover, so this test couldn't be performed for RethinkDB yet. But when we implement automatic failover we're planning to test it against Jepsen. That will probably be sometime in the next few months.
Re: Call Me Maybe: MongoDB Stale Reads
#25Earlier quoted context omitted.
That island of safety is a rapidly shrinking one. Jepsen covers more ground with each new post from Kyle. :)
Has there been any CP system passing a call-me-maybe test first time apart from Zookeeper [1]? [1] https://aphyr.com/posts/291-call-me-maybe-zookeeper
Re: Call Me Maybe: MongoDB Stale Reads
#26Earlier quoted context omitted.
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 ac…
I don't think the results of Aphyr's MongoDB and postgres experiments are directly comparable. In the OP, MongoDB was run in a 5 node replicated configuration. In the post you reference, the experiment was run against a single postgres node.
Furthermore, the postgres experiment only checked that no writes were lost. As Aphyr acknowledges, MongoDB did not lose any writes with "majority" write concern. The postgres experiment did not include the verification of a linearizable history of reads, which is what the bulk of the OP is about.
I'd like to see a similar experiment run against a replicated postgres configuration with auto-failover.
Re: Call Me Maybe: MongoDB Stale Reads
#27I knew something was funny with Mongo when all the api calls defaulted to writes not being guaranteed to sync to disk. Maybe for a use case like aggregate statistics gathering it would be ok to risk missing a few updates in a crash for the sake of speed, but to make that the default??
Re: Call Me Maybe: MongoDB Stale Reads
#28Mongo absolutely nailed creating a database that is easy to get started with and even do things that are traditionally more 'hard' such as replication. It is still super attractive for me to pick it up for small projects, even after dealing with its (many) pain points both in development and operational settings.
Given this, it is so tragic to see how dismissive they have been in regards to the consistency issues that have plagued the db since the early days. Whether it was the stupidity of bad defaults in drivers to not confirm writes, or easily corruptible data in the 1.6 days, or now with not seriously looking at the results of jepsen, the mongodb organization has never taken the issues head on. It would be so refreshing to see more transparency and admitting to the faults rather than wiggling around them until eventually pushing a fix buried in patch notes.
I often feel like a mongodb apologist when I admit that I don't mind using mongo for small (and not important) projects and while the mongodb hate can be a bit extreme at times, the companies treatment of these sorts of issues may justify some of it.
Re: Call Me Maybe: MongoDB Stale Reads
#29Earlier quoted context omitted.
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 ac…
Now try it again with PostgreSQL's built in sharding or replication functionality... oh, wait.
Re: Call Me Maybe: MongoDB Stale Reads
#30Earlier quoted context omitted.
Has there been any CP system passing a call-me-maybe test first time apart from Zookeeper [1]? [1] https://aphyr.com/posts/291-call-me-maybe-zookeeper
Postgres: https://aphyr.com/posts/282-call-me-maybe-postgres
Postgres can survive a network partition? I wasn't aware that master-master or sharding+replication was in the box yet?