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

201–210 of 416 posts

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#201

Post by mathattack »

icedchai wrote: post #182
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…

Isn't it amazing MongoDB is a 12 billion dollar company? Someone is using it and actually paying for it, even though it's not any of the developers you or I know.

It’s the switching costs to get rid of it...

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#202

Post by pnako »

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…

>* H2: My company can't afford a database admin, so I embedded the database in our application (I have actually done this)

I'm familiar with the variant, "InfoSec won't let us deploy a DB on the same host".

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#203

Post by Gaelan »

scarface74 wrote: post #39
Smaug123 wrote: post #33

Earlier quoted context omitted.

I trust Kyle when he tells me that the behaviour he observes is surprising. From the analysis ( https://jepsen.io/analyses/mongodb-4.2.6 ): "In order to obtain snapshot isolation, users must be careful not only to set the read concern to snapshot for each transaction, but also to set write concern for each transaction to majority. Astonishingly, this applies even to read-only transactions." "This behavior might be su…

There is difference between “Mongo’s documentation sucks” and “Mongo is technically deficient”. The former can be corrected by updating the documentation. Yes, I agree as far as the end user is concerned, they are losing data either way.

I think the implication here is that "Mongo's documentation is deliberately bad in order to hide their technical deficiencies," i.e. they're hoping people will use the defaults, be impressed by the speed, and never realize until it's too late that they're not getting the consistency they were promised.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#204

Post by ianamartin »

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 much more like a distributed file system that has queuing semantics baked in than it is an ephemeral queue that implements some level of persistence.

The fact that you put Kafka and RabbitMQ in the same category sort of makes me feel like you're out of your element, Donnie.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#206

Post by Ice_cream_suit »

There is much amusement to be obtained from reading Jepsen's report:

"MongoDB’s default level of write concern was (and remains) acknowledgement by a single node, which means MongoDB may lose data by default.

...Similarly, MongoDB’s default level of read concern allows aborted reads: readers can observe state that is not fully committed, and could be discarded in the future. As the read isolation consistency docs note, “Read uncommitted is the default isolation level”.

We found that due to these weak defaults, MongoDB’s causal sessions did not preserve causal consistency by default: users needed to specify both write and read concern majority (or higher) to actually get causal consistency. MongoDB closed the issue, saying it was working as designed"

http://jepsen.io/analyses/mongodb-4.2.6

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#207

Post by kyllo »

jen20 wrote: post #177
kyllo wrote: post #128

Earlier quoted context omitted.

I was floored by this comment yesterday from one of their Developer Relations people: > Did any of you actually read the article? We are passing the Jepsen test suite and it was back in 2017 already. So, no, MongoDB is not losing anything if you know what you are doing. https://twitter.com/MBeugnet/status/1253622755049734150?s=20 Can you imagine saying the phrase "if you know what you are doing," in public, to your u…

Firstly let me point out that this response is neither intended as a defence of MongoDB defaults which are atrocious, or of the company, who are arguably duplicitous. However I can _quite easily_ see how a non-native English speaker could use the phrase “if you know what you are doing” to mean “if you are careful”.

Perhaps, but the point is, if you're working in DevRel and you think your role is to defend the product from criticism, and you do it by placing the onus on the developer to figure out how to use your product safely, you've totally lost the plot.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#208

Post by isatty »

erulabs wrote: post #186

I wonder if I'm the only sysadmin in the world who doesn't hate MongoDB. Yes, I wouldn't use it for new projects, and yes, I wish RethinkDB had taken its place, but it's not as horrible as people seem to think. Default configuration... If it weren't for RDS' doing PG-bouncer-style connection management, 95% of production postgres instances would probably fail. It innodb_buffer_pool_size wasn't set properly, plenty of…

> You can learn a lot about a developer by asking "What do you think about Mongo, JavaScript, or PHP", and if their response isn't a shrug, they're probably more concerned with what editor is correct than if the product they're building is useful. It's an exceptional filter to reject zealots and find pragmatists.

Sure, if they’re being rude about it. A developer saying that it will not fit the use case or talking about spending a month of their time fixing a production issue caused by MongoDB will definitely not get a “no” from me. I’m not hiring subservient people I’m hiring people who can think for themselves and choose the right tool for the job, which Mongo rarely is.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#209

Post by nieve »

ceocoder wrote: post #96
henryfjordan wrote: post #94

Earlier quoted context omitted.

RabbitMQ stores your data, right? Then it's a database! That's pretty much all it takes. A flat file, memory-store, SQL DB, Document store, any of them can be databases if that's where you stick your data! But also no, RabbitMQ and Kafka and the like are clearly message buses and though they might also technically qualify as a DB it would be a poor descriptor.

Ah I see, we are going with “well technically it stores something therefore it is database joke”. Now I’m fully onboard :) Back when I worked in LA my CTO used to joke that most places use Microsoft Outlook as a database and Excel as BI tool.

If memory serves the original EToys.com code treated the filesystem as tree-structured database using atomic operations (though no transactions). It worked just fine, then the rewrite with an RDBMS that should have been stabler and faster resulted in the famous meltdowns. Admittedly this is cheating a bit since you can name folders & files with semi-arbitrary or internally structured string keys. By 1997 standards pure disk access without having to walk the filesystem heirarchy was blazingly fast compared to many of the databases I was using.

[Source: I was friends with the guy who wrote it as well as other EToys employees. God that was a trainwreck.]

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#210

Post by jagannathtech »

VonGuard wrote: post #195

Lying about your test results from Jepsen is like going onto a reality show with Chef Ramsey, being thrown off for incompetence, then putting his name on your restautant's ads "Chef Ramsey ate here!" I'd pay to watch Kyle screaming at people in the MongoDB offices, not that he screams or anything. Just a spectacular mental image: "IT'S NOT ATOMIC! IT COULDN'T SERIALIZE A DOG'S DINNER!"

I would watch a tech version of Ramsey's show.. oh boy!
Post reply on HN