Jepsen Disputes MongoDB's Data Consistency Claims • Hacker News Board

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#111

Post by Hamuko » Sat, May 23, 2020, 10:15 PM UTC

ceocoder wrote: post #91

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…

This might be a stupid question, but surely no one thinks of RabbigMQ as a database right? I’ve used it from 2012 to 2018 extensively, including using things like shovels to build hub spoke topologies, however not once did I think of it as anything but a message broker. Did I miss something huge?

>This might be a stupid question, but surely no one thinks of RabbigMQ as a database right?

Arguably the world's most popular database is Microsoft Excel.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#112

Post by detaro » Sat, May 23, 2020, 10:17 PM UTC

ceocoder wrote: post #91

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…

This might be a stupid question, but surely no one thinks of RabbigMQ as a database right? I’ve used it from 2012 to 2018 extensively, including using things like shovels to build hub spoke topologies, however not once did I think of it as anything but a message broker. Did I miss something huge?

I interpret it as they'd probably not call it a database, but they might use it in places where a database would be better suited, and effectively store data in it.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#113

Post by gav » Sat, May 23, 2020, 10:18 PM UTC

otterley wrote: post #47

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…

When I'm thinking about data stores in large systems I like to break them down depending on how they are used on two main axes: is it fast/slow moving and durability from "we don't care" and "we must never lose data".

It's easier to reason about systems if there's fewer things that require durability guarantees, ideally you want to be able to draw data flows that look like a tree instead of a graph.

I find that Redis fits great because it's perfect for a whole bunch of different temporal shared state needs, everything from sessions to partial results. I've also deployed things like Ehcache, MongoDB, and Memcached to fit these needs and found other tools such as Kafka or RabbitMQ to be great "glue".

Having the root of your important data be something "boring" like Postgres or MySQL (or even Oracle!) is just good risk management to me. I wouldn't want to trust Redis or MongoDB for important data because it adds to the things I have to worry about. It's "keeping your eggs in one basket" while making sure that basket is really well looked after.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#114

Post by hypewatch » Sat, May 23, 2020, 10:20 PM UTC

Diederich wrote: post #104

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…

> but there is no MongoDB use in Facebook hasn't been for years Are you sure?

It’s certainly not used for any mission critical apps. Facebook’s stack is pretty well known. They’ve been using sharded MySQL for a while now. Instagram started on PostgreSQL but I believe has switched to Cassandra.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#115

Post by Diederich » Sat, May 23, 2020, 10:23 PM UTC

hypewatch wrote: post #114

Diederich wrote: post #104

Earlier quoted context omitted.

> but there is no MongoDB use in Facebook hasn't been for years Are you sure?

It’s certainly not used for any mission critical apps. Facebook’s stack is pretty well known. They’ve been using sharded MySQL for a while now. Instagram started on PostgreSQL but I believe has switched to Cassandra.

> mission critical apps

Thanks for the clarification.

As an example: would you consider the backend software stack that manages physical access to the campus 'mission critical'?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#116

Post by kevinburke » Sat, May 23, 2020, 10:24 PM UTC

dang wrote: post #54

twoodfin wrote: post #9

Discussed previously: https://news.ycombinator.com/item?id=23191439

Surprisingly, it seems not to have made the front page: http://hnrankings.info/23191439/ . There's clearly community appetite to discuss this, so we won't treat the current submission as a dupe.

“ Did HN's antispam measures get a lot more aggressive recently? The last handful of Jepsen reports have really struggled to make it to frontpage, despite significantly higher vote-to-age ratios than comparable posts. Once they're on FP, they reliably hit top 10, but Dgraph's (1/2) ” https://twitter.com/jepsen_io/status/1261640852666855426

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#117

Post by maevyn11 » Sat, May 23, 2020, 10:24 PM UTC

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…

ha, nailed it dude.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#118

Post by hypewatch » Sat, May 23, 2020, 10:29 PM UTC

Diederich wrote: post #115

hypewatch wrote: post #114

Earlier quoted context omitted.

It’s certainly not used for any mission critical apps. Facebook’s stack is pretty well known. They’ve been using sharded MySQL for a while now. Instagram started on PostgreSQL but I believe has switched to Cassandra.

> mission critical apps Thanks for the clarification. As an example: would you consider the backend software stack that manages physical access to the campus 'mission critical'?

I would not. Facebook.com still operates with or without that system. Especially now with COVID-19, I’m sure it’s not being used at all.

Mission critical - essential for operating Facebook.com

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#119

Post by kabes » Sat, May 23, 2020, 10:33 PM UTC

benibela wrote: post #109

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 if they prefer an XML database (like basex, exist, marklogic)?

Psychopath

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#120

Post by ncmncm » Sat, May 23, 2020, 10:37 PM UTC

threeseed wrote: post #65

ncmncm wrote: post #44

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 sp…

If they only cared about performance then they would've left the write concern defaults to not acknowledge writes either locally or within a replica set. Or just read from the nearest replica and don't worry about potential consistency issues. Also this isn't 2011. MongoDB is not a competitor to Oracle and never really has been by people that knew that a DocumentDB was not usable as a SQL one. It's other SQL database…

You know it, I know it, MDB knows it, and most of their customers know it, but that doesn't matter: the stock market doesn't. MDB wants to be valued like a durable-database company, and to be able to charge durable-database prices. They need a plausible durable-database story to get those, regardless of what actual current users want.

It is possible there are still potential users not buying until they get that story. MDB wants those users.