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

71–80 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#71

Post by pengaru »

threeseed wrote: post #59
pengaru wrote: post #13

Earlier quoted context omitted.

Maybe they're too busy spending their MDB money. https://www.google.com/search?q=NASDAQ:+MDB

I genuinely am confused by comments like this. Are companies not supposed to invest money into their product, sales, people etc ? And why does being listed on the NASDAQ imply being flush with money ?

> Are companies not supposed to invest money into their product, sales, people etc ?

> And why does being listed on the NASDAQ imply being flush with money ?

It was intended to be a playful reference to MDB's stock price being on a tear right now, not simply being listed on NASDAQ.

Expand the timeline on the graph to "Max", it's at an all time high.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#72

Post by tpxl »

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.

For what it's worth, Document DB doesn't support a lot of the Mongo API, such as $$ROOT in aggregations, and it can't use indices on (paraphrased) "SELECT * FROM x WHERE id IN [list]" if the list length is > 10.

If you ask me, if there's something worse than Mongo it's Document DB.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#73

Post by yawaramin »

thomascgalvin wrote: post #53

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

I have other boats to rock than MySQL! ;-)

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#74

Post by tester756 »

thomascgalvin wrote: post #53

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

What about MSSQL?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#75

Post by bjt »

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.

> It's not really that different than dumping your JSON in a TEXT column

That was true of the initial "JSON" type support.

It is very much not true of the "JSONB" type, which was added in 2014 as part of Postgres 9.4. JSONB uses a binary serialization that supports efficiently selecting into JSON documents, putting regular BTREE indexes on specific fields inside the documents, or even putting Elasticsearch-like inverted indexes on complete JSON documents.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#76

Post by Thaxll »

castorp wrote: post #61
Thaxll wrote: post #46

Earlier quoted context omitted.

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...

> MySQL and PG are not truly consistent per default, they don't fsync every writes. Postgres most certainly does fsync by default. It's tru, you can disable it, but there is a big warning about "may corrupt your database" in the config file.

No PG does not fsync every writes, more details here: https://dba.stackexchange.com/questions/254069/how-often-doe...

My point is people complain about MongoDB are the one not using it most likely, MongoDB is very different from 10 years ago.

I like to remind people that PG did not have an official replication system 10years ago and as of today is still behind MySQL. No DB is perfect, it's about tradeof.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#77

Post by tjalfi »

thomascgalvin wrote: post #53

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

SQL Server: I use C# and write line-of-business applications.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#78

Post by wolf550e »

Thaxll wrote: post #46
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...

The default in MySQL and in postgresql is to fsync before commit and afaik that has always been the default.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#79

Post by beardbandit »

threeseed wrote: post #57
thomascgalvin wrote: post #53

You can tell a lot about a developer by their preferred database. * Mongo: I like things easy, even if easy is dangerous. I probably write Javascript exclusively * MySQL: I don't like to rock the boat, and MySQL is available everywhere * PostgreSQL: I'm not afraid of the command line * H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this) * SQLite: I'm…

And you can tell a lot about a developer when they post comments like this. Almost none of is remotely accurate e.g. RabbitMQ isn't even a database.

Man, people really hate Mongo.

We use it for a very specific use case and its been perfect for us when we need raw speed over everything. Data loss is tolerable.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#80

Post by collyw »

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…

Maybe it's just because I know SQL reasonably well but I don't even find Mongo particularly easy to use. Not for complex queries anyway.
Post reply on HN