Live data from Hacker News

Jepsen Disputes MongoDB's Data Consistency Claims

infoq.com

81–90 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#81
post #76
post #61

Earlier quoted context omitted.

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

> It writes out and syncs the accumulated WAL records at each transaction commit, unless the committed transaction touched only UNLOGGED or TEMP tables, or synchronous_commit is turned off.

So wal is synced before commit returns, and if you power cycle immediately after, the wal is played back and your transaction is not lost? So it's fine?

It does not need to sync all writes, only the records needed to play back the transaction after restart. This is what all real databases do.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#82
post #51
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…

Reading past marketing blurbs and using products for the things they are designed is part of any engineer's job. I was irritated by MongoDB's claims and defaults, but that didn't stop us from putting it in production. We used it from 2012 to 2016 (their most infamous years?), and for our use cases, scale, size+expertise, and feature set, it was a perfect match. In our case, durability was a smaller concern by design…

>In our case, durability was a smaller concern by design (lots of write-only data, lots of ephemeral data),

I assume that you mean write once data. If you mean write only you might as well use /dev/null.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#83

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…

As someone who chose MySQL and provides direction to developers who really like Postgres, and who also uses Postgres for fun, I do find myself having to both defend MySQL as a prudent option and convince them that I know anything at all about Postgres or computer science. :)

I've heard MySQL (well, MariaDB, really) has improved a lot in recent years, but I still can't imagine why I'd ever choose it over Postgres for a professional project. Is there any reason?

It used to be that bargain basement shared-hosting providers would only give you a LAMP stack, so it was MySQL or nothing. But if you're on RDS, Postgres every time for my money.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#84
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…

> Or people care more about speed and ease of use than durability I think 90% of the Mongo installs I've been exposed to were set up by people that were tired of fighting with Hibernate configurations and schema migrations. It's also popular among people whose definition of "legacy software" is "that app I stopped working on after three months because I have something shiny and new."

We have it at our work. I bet it's because it was the hip new thing to try out in 2013. Our tech lead is more into tech challenges than building a maintainable app.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#85

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

I really enjoy using PostgreSQL only I just don't know how to make it scale easily. Running it on large VM in the cloud works fine until you have lots of data or need it easily accessible. How can you have the data in three different regions (e.g. Europe, US, Asia) when you using something like Google Cloud? Seems to be a hard problem to crack.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#86
Typical HN posts of late hating on Javascript and MongoDB from database elitists -- the thing is there's a tool for a job and as engineers we need to figure out what tool best suits our use cases. It could very well be a NoSQL database such as Mongo or a relational one like Postgres or MySQL.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#87
post #12

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.

The damage is done. I have to use this crap at work when we should be using an SQL database. We have been planning a migration since before I started a year and a half ago. I won't be surprised if we are still on Mongo in another year and a half.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#88

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…

I got my pm friend prototype his idea on mean stack, but when we got more serious, immediately transitioned to postgres and started using sequelize as the orm. Pretty good decision so far. I don't think they will have cases that won't scale with orm for foreseeable future.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#89
post #49
post #12

Earlier quoted context omitted.

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.

I remember the Mongo hype when it came out and I really couldn't understand it. You are just throwing away a lot of useful features of a relational database because "schemaless" and "big data". The majority of people using it were on single server setups.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#90

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.

I can't believe the one item that was so obviously added as a joke went right over head.

It may be good idea to take a break from the computer and find something less stressful to do.

Post reply on HN