Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

Post reply on HN
Print view View original

41–50 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#41

Post by why-el »

pletnes wrote: post #22
aeonsky wrote: post #20

Earlier quoted context omitted.

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.

DB noob question: if you know that you should be indexing on a json attribute, can’t you put it into a «proper column» and index there?

You could, of course. But that would mean that you are effectively not using json anymore. You need to pull the data out of your json on each write, update in two places, and so on. And if you need to delete a json column, what do you do with the other one? You need to delete it also. You are then managing two things.

There is always a trade off. If the column is important enough, then you are right, it should stand on its own, but then you lose the json flexibility. I personally almost always only use jsonb if I know I only care about that overall object as a whole, and rarely need to poke around to find an exact value. As a the grandparent comment mentions, if you do need a particular value, then it might be slower if your JSON records are too different (if you think about it, how can you calculate selectivity stats on a value if you have no idea how wide or different JSON records are?).

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#42

Post by throwanem »

hartator wrote: post #34
toomuchtodo wrote: post #19

Earlier quoted context omitted.

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.

> Why not use PostgreSQL instead? It supports a JSON document data type natively. Yes, that's the thing, it's just a field type. It's not really that different than dumping your JSON in a TEXT column. MongoDB is fun because it's truly JSON - BSON - so you don't have to run migrations, you can store complex documents, and have a more object oriented way of storing your data than SQL.

You should probably read the Postgres documentation [1] before you make erroneous claims like this. Postgres JSON fields can be destructured, queried, and aggregated sufficiently to cover at least the 90% cases in MongoDB usage.

I'll grant that Postgres probably isn't as much fun as Mongo, what with all its tiresome insistence on consistency and reliability. I would, however, argue that quantity of available fun isn't really a figure of merit here.

[1] https://www.postgresql.org/docs/10/functions-json.html

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#43

Post by threeseed »

Hydraulix989 wrote: post #15

This has been a known issue for a while: https://hackingdistributed.com/2013/01/29/mongo-ft/ MongoDB: Broken By Design

Might want to read up as this involves a completely different set of issues.

And most of those listed in the blog were fixed many years before 2013.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#44

Post by ncmncm »

MongoDB's big problem is that their present user base does not want the problems fixed, particularly at default settings, because it would mean going slower. Their users are self-selected as not caring much about integrity and durability. There are lots of applications where those qualities are just not very important, but speed is. People with such applications do need help with data management, and have money to spend on it.

The stock market wants to see the product as a competitor with Oracle, so demands all the certifications that say so. MongoDB marketing wants to be able to collect money as if the product were competitive. Many of the customers have management that would be embarrassed to spend that kind of money on a database that is not. And, ultimately, many of the applications do have durability requirements for some of the data.

So, MongoDB's engineers are pulled in one direction by actual (paying) users, and the opposite direction by the money people. It's not a good place to be. They have very competent engineers, but they have set themselves a problem that might not be solvable under their constraints, and that they might not be able to prove they have solved, if they did. Time spent on it does not address what most customers want to see progress on.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#45

Post by doublesCs »

scarface74 wrote: post #40
doublesCs wrote: post #37

Earlier quoted context omitted.

Oops. Turns out I was right. https://news.ycombinator.com/item?id=23271211 The timing of this is absolutely beautiful.

So now we shouldn’t ever trust a project because they don’t have good technical writers? I don’t have a dog in the Mongo fight. I haven’t done an implementation on top of it in years and probably the next time I do something with “Mongo” it will probably be AWS’s Document DB with Mongo support. That’s based on AWS’s own code and storage tier and doesn’t have the same characteristics as Mongo proper.

> So now we shouldn’t ever trust a project because they don’t have good technical writers?

> the newer MongoDB 4.2.6 has more problems including “retrocausal transactions” where a transaction reverses order so that a read can see the result of a future write.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#46

Post by Thaxll »

naked-ferret wrote: post #5

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…

MySQL and PG are not truly consistent per default, they don't fsync every writes.

MongoDB explains that pretty well: https://www.mongodb.com/faq and https://docs.mongodb.com/manual/core/causal-consistency-read...

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#47

Post by otterley »

jedberg wrote: post #29

MongoDB started life as a database designed for speed and ease of use over durability. That's not a good look for a database. People have told me that they have since changed, but the evidence is overwhelmingly and repeatedly against them. They seem to have been successful on marketing alone. Or people care more about speed and ease of use than durability, and my assumptions about what people want in a database are j…

> MongoDB started life as a database designed for speed and ease of use over durability. That's not a good look for a database.

I think it depends. One could say the same about Redis, but it's wildly successful and people love it.

The difference is now they are advertised. Redis makes no claims to be anything other than what it is - a fast in-memory database that has some persistence capability but isn't meant to be a long-term data store. MongoDB, on the other hand, made (and continues to make) claims about being comparable in atomicity and durability to traditional SQL databases (but magically much faster!) that haven't withstood scrutiny.

Keep in mind, too, that most data ain't worth much. It's one thing to entrust data of low value in MongoDB; another to store mission-critical data in it. I would look askew at leadership who didn't ask hard questions about storing data worth millions or billions of dollars in MongoDB without frequent snapshots -- and even then, the value mustn't be contingent on the 100% accuracy of said data.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#48

Post by MrBuddyCasino »

macintux wrote: post #36
madhadron wrote: post #27

In the circles I run in, MongoDB is regarded as a joke and the company behind it as basically duplicitous. For example, they still list Facebook as their first user of MongoDB on their website, for example, but there is no MongoDB use in Facebook hasn't been for years (it came in only via a startup acquisition). I had the misfortune to use MongoDB at a previous job. The replication protocol wasn't atomic. You would f…

The joke I learned early on: "Migrating away from Mongo is trivial: wait long enough, and all your data will be gone anyway." I imagine things are better now.

MongoDB: the Snapchat of databases.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#49

Post by znpy »

senko wrote: post #12
saagarjha wrote: post #6

Earlier quoted context omitted.

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.

i remember diaspora chanting about using mongodb.

then a year or two later they admitted that their data model mostly fitted the relational model, and that they spent a lot of time basically reimplementing relational integrity in application code, in ruby.

yeah, diaspora has never been fast. I'm not sure they can blame it on mongodb though.

Post reply on HN