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

141–150 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#141

Post by tonigen »

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…

MySQL is actually amazing, scale better than PGsql supports Json and is available everywhere. I see no reason to use any other dB for 90% of the use cases u need a dB for

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#142

Post by namibj »

twic wrote: post #139
johannes1234321 wrote: post #125

Earlier quoted context omitted.

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?

2 years ago, they were worse, from what I recall.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#143

Post by larrik »

ashtonkem wrote: post #130
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 prefer PostgreSQL, but MySQL provides a better clustering experience if you need more read capacity than a lone node can provide. Oracle is great if and only if you have a use case that fits their strengths you have an Oracle specific DBA, and you do not care about the cost. I have been on teams where we met those criteria, and I genuinely had no complaints within that context .

Given both my experience and prior research, I don't believe you that Oracle is ever better than have the stuff on the above list, and I think it's worse than Postgres on every metric.

Every time I need to work with an Oracle DB it costs me weeks of wasted time.

For a specific example, I was migrating a magazine customer to a new platform, and all of the Oracle dumps and reads would silently truncate long textfields... The "Oracle experts" couldn't figure it out, and I had to try 5 different tools before finally finding one that let me read the entire field (it was some flavor of JDBC or something). To me, that's bonkers behavior, and is just one of the reasons I've sworn them off as anything other than con artists.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#145

Post by dustingetz »

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…

Datomic: I'm done already, send more work please

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#146

Post by erik_seaberg »

scarface74 wrote: post #31
Smaug123 wrote: post #28

Earlier quoted context omitted.

Kyle's point is that it's arguably valid but certainly unhelpful: the default settings are liable to lead to data loss. Moreover, he draws attention specifically to transactions as something which you would expect to make things safer, but in fact there's a rather arcane part of the documentation that notes that you need to manually specify both read and write concerns on every transaction individually if you want tr…

How is this any different than DynamoDB where you specify that you want either eventual consistency vs strong consistency? DDB also does eventual consistent reads by default. Is the argument that Mongo’s documentation isn’t clear?

DynamoDB conditional writes are strongly consistent. Defaulting to inconsistent reads was reckless and I would never defend that, but the worst case is non-repeatable stale results, never lost writes.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#147

Post by dijit »

tonigen wrote: post #141
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…

MySQL is actually amazing, scale better than PGsql supports Json and is available everywhere. I see no reason to use any other dB for 90% of the use cases u need a dB for

MySQL does not scale better than PostgreSQL.

I can tell you this emphatically as I spent 6 months trying to eke out performance with MySQL (5.6). PostgreSQL (9.4) handled the load much better without me having to change memory allocators or do any kind of aggressive tuning to the OS.

MySQL has some kind of mutex lock that stalls all threads, it's not noticeable until you have 48cores, 32 databases and a completely unconstrained I/O.

EDIT: it was PG 9.4 not 9.5

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#148

Post by dijit »

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

Ubiquity Edgerouters' management interface has a MongoDB backend and I have one on my desk at work, but I would not consider that I run "MongoDB" to provide services for my customers.

In much the same way I wouldn't say that my site is powered by Microsoft Excel; but you can be sure Microsoft Excel is used in my company.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#149

Post by [deleted] »

Hamuko wrote: post #111
ceocoder wrote: post #91

Earlier quoted context omitted.

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.

[deleted]

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#150

Post by dijit »

Thaxll wrote: post #134
wolf550e wrote: post #78

Earlier quoted context omitted.

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.

That bug was unfortunate, but you can't say that "it doesn't fsync" because, pedantically, it does, it just ignores the return value.

And, obviously that's a bug, it's designed to do so.

Also, if you write with O_DIRECT, a fsync is not needed, as it's how you tell the OS to block until written.

Post reply on HN