Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

11–20 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#11
post #2

Oh, Jepsen and MongoDB again? Somebody get the popcorn!

Unfortunately, not an entertaining showdown - too one-sided.

I remember having immensely enjoyed the original "Call me maybe" analysis [https://aphyr.com/posts/284-jepsen-mongodb]. Sometimes it's just fun to see someone beaten.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#12

Earlier quoted context omitted.

Unfortunately, not an entertaining showdown - too one-sided.

Because MongoDB is web scale?

Some readers might not be familiar with that particular meme: https://m.youtube.com/watch?v=b2F-DItXtZs

IMHO it perfectly describes the hype-reality disconnect at the early days of MongoDB. Yeah it was that bad.

Mongo has improved since, the hype has toned down and the NoSQL space is more crowded these days.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#14
"We found that due to these weak defaults, MongoDB’s causal sessions did not preserve causal consistency by default: users needed to specify both write and read concern majority (or higher) to actually get causal consistency. MongoDB closed the issue, saying it was working as designed, and updated their isolation documentation to note that even though MongoDB offers “causal consistency in client sessions”, that guarantee does not hold unless users take care to use both read and write concern majority. A detailed table now shows the properties offered by weaker read and write concerns."

That sounds like a valid redress, or am I missing something ?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#16

From the jepsen report: """ Curiously, MongoDB omitted any mention of these findings in their MongoDB and Jepsen page. Instead, that page discusses only passing results, makes no mention of read or write concern, buries the actual report in a footnote, and goes on to claim: > MongoDB offers among the strongest data consistency, correctness, and safety guarantees of any database available today. We encourage MongoDB t…

From top of linked article: >>> I have to admit raising an eyebrow when I saw that web page. In that report, MongoDB lost data and violated causal by default. Somehow that became "among the strongest data consistency, correctness, and safety guarantees of any database available today"! It's not wrong, just misleading. Seems overblown given that most practitioners know how to read this kind of marketing speak.

> It's not wrong, just misleading. Seems overblown given that most practitioners know how to read this kind of marketing speak.

So basically whatever MongoDB was doing 10 years ago, they are continuing to do there. They did not change at all, yesterday or two days ago there were few people defending mongo that indeed in early years mongo want the greatest, but it is now and people should just stop being hang up in the past.

The reason why people lost their trust with mongo wasn't technical, it was this.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#17
[repost - asking for help] I am disappointed with the direction that MongoDB took this past few years. Going ACID shows in benchmarks [1] and it’s not advisable if you are using MongoDB for stats and queue. (No one uses MongoDB for financial transactions despite the changes.)

And the recent change to a restrictive license is worrisome as well. I have been thinking of forking 3.4 and make it back to “true” open source and awesome performance. (If any C++ devs want to help out, reach out to me! username @gmail.com)

[1] https://link.medium.com/PXIeZfhhH6

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#18

Earlier quoted context omitted.

From top of linked article: >>> I have to admit raising an eyebrow when I saw that web page. In that report, MongoDB lost data and violated causal by default. Somehow that became "among the strongest data consistency, correctness, and safety guarantees of any database available today"! It's not wrong, just misleading. Seems overblown given that most practitioners know how to read this kind of marketing speak.

I appreciate your optimism in thinking that most (all?) people reaching for distributed systems actually know enough in the space to evaluate such claims.

Agree, and the "Mongo and Jepsen" page isn't targeting distributed systems experts, most of them know to stay away, because even if there are things that mongo does right, other systems do it better.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#19

[repost - asking for help] I am disappointed with the direction that MongoDB took this past few years. Going ACID shows in benchmarks [1] and it’s not advisable if you are using MongoDB for stats and queue. (No one uses MongoDB for financial transactions despite the changes.) And the recent change to a restrictive license is worrisome as well. I have been thinking of forking 3.4 and make it back to “true” open source…

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project.

Mongo should never be a first choice, but a last choice for edge cases.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#20

[repost - asking for help] I am disappointed with the direction that MongoDB took this past few years. Going ACID shows in benchmarks [1] and it’s not advisable if you are using MongoDB for stats and queue. (No one uses MongoDB for financial transactions despite the changes.) And the recent change to a restrictive license is worrisome as well. I have been thinking of forking 3.4 and make it back to “true” open source…

Why not use PostgreSQL instead? It supports a JSON document data type natively. It also has exceptional stewardship as an open source project. Mongo should never be a first choice, but a last choice for edge cases.

Postgres has terrible indexing with json. It doesn’t keep statistics so simple queries sometimes take much longer than expected due to query planner not knowing much about the data.
Post reply on HN