Oh, Jepsen and MongoDB again? Somebody get the popcorn!
Unfortunately, not an entertaining showdown - too one-sided.
Jepsen Disputes MongoDB's Data Consistency Claims
11–20 of 416 posts
Re: Jepsen Disputes MongoDB's Data Consistency Claims
#12Earlier quoted context omitted.
Unfortunately, not an entertaining showdown - too one-sided.
Because MongoDB is web scale?
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
#13I think it's remarkable this report has been out for a week now and no one at MongoDB has commented on it. At least, not that I have seen.
Re: Jepsen Disputes MongoDB's Data Consistency Claims
#14That sounds like a valid redress, or am I missing something ?
Re: Jepsen Disputes MongoDB's Data Consistency Claims
#15https://hackingdistributed.com/2013/01/29/mongo-ft/
MongoDB: Broken By Design
Re: Jepsen Disputes MongoDB's Data Consistency Claims
#16From 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.
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
#17And 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)
Re: Jepsen Disputes MongoDB's Data Consistency Claims
#18Earlier 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.
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…
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.