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

131–140 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#131

Post by ashtonkem »

ceocoder wrote: post #93
wzy wrote: post #90

Earlier quoted context omitted.

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.

Perhaps that’s because some other message brokers are now being touted as databases[0][1], I remember seeing a thread about it on HN couple of days ago. [0] https://www.confluent.io/blog/okay-store-data-apache-kafka/ [1] https://dzone.com/articles/is-apache-kafka-a-database-the-20...

Kafka is a very different beast from RabbitMQ.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#132

Post by anaphor »

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…

SQLite: I enjoy using reliable and correct databases even at the cost of scalability

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#133

Post by squeaky-clean »

polote wrote: post #122
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…

Nobody seems to like it. Someone has any idea on why the company still has their revenue increasing ?

I like it, but I don't really really chime in on threads where it's mostly Mongo bashing and jokes, and I'm guessing others who like MongoDB do the same.

But I'd think MongoDB the company increasing in revenue isn't totally related to the quality of MongoDB the database. In fact a lot of their products seem to be targeting the "I don't want to learn how to set it up and understand indexes" crowd.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#134

Post by Thaxll »

wolf550e wrote: post #78
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...

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

Not it was not the case and there was several serious issues with fsync and PG in the past: https://www.percona.com/blog/2019/02/22/postgresql-fsync-fai...

On MySQL: https://dev.mysql.com/doc/refman/8.0/en/innodb-dedicated-ser...

InnoDB uses O_DIRECT during flushing I/O, but skips the fsync() system call after each write operation.

The fsync thing is more complex than it looks like.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#135

Post by PacifyFish »

tehlike wrote: post #88
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…

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.

How do you manage dev vs prod instances with sequelize? Specifically, do you use migrations for your local dB or just force sync it?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#136

Post by Thaxll »

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…

How MongoDB is dangerous or less consistant that PG? I have one for you: I can't use PG or MySQL because my app will go down if the master is down so then the entire backend fails. How do you do HA with default PG?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#137

Post by toast0 »

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'?

Sure, that's mission critical (ish), but it's not really what people think of when they think of Facebook. It's not millions of posts per second, ultra scalable whatever.

Disclosure: I worked at Facebook, but not in that department, or anywhere near any MongoDB.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#138

Post by twic »

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 once worked on a system for notifying customers of events by posting to their APIs. Events came in on a Rabbit queue and got posted.

If a customer's API was down, the event would go back on the queue with a header saying to retry it after some time. You can do some sort of incantation to specifically retrieve messages with a suitable header value, to find messages which are ready to retry. We used exponential backoff, capped at one day, because the API might be down for a week.

I didn't think of RabbitMQ as a database when I started that work, but it looked a lot like it by the time I finished.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#139

Post by twic »

johannes1234321 wrote: post #125
gav wrote: post #101

Earlier quoted context omitted.

I tend to find people who argue with me against MySQL bring up things that haven't been true in a long time such as Unicode or NULL handling. I'd probably choose Postgres over MySQL for a new project just to have the improved JSON support, but there's upsides to MySQL too: - Per-thread vs per-process connection handling - Ease of getting replication running - Ability to use alternate engines such as MyRocks

MySQL also has great JSON features (json data type, virtual indexes onnit, multi-value (array) indexes, json_table, ....)

I'd be impressed if these were better than PostgreSQL's JSON features. Do you know how they compare?

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#140

Post by haimez »

collyw wrote: post #82
Jare wrote: post #51

Earlier quoted context omitted.

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.

The performance gains are very impressive https://tech.wayfair.com/2013/04/devnull-vs-mongodb-benchmar...
Post reply on HN