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

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#391

Post by thaumasiotes » Sun, May 24, 2020, 8:07 PM UTC

skywhopper wrote: post #351

thaumasiotes wrote: post #290

Earlier quoted context omitted.

> 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”. This kind of thing is a scourge. I had a Chinese friend respond to something I said once by saying "that's nice". It looks so innocent... but it's really hard to overlook the fact that "that's nice" is a serious insult coming from a native speaker. I had to ask them to please…

Wow! Where are you from that you consider it a "fact" that "that's nice" is a "serious insult"? (I'm genuinely curious... I assume not the US based on the time this was posted?) To my ear (American who grew up in the South, lives in the Midwest, and works with people largely from the Mountain West), "that's nice" could definitely be used dismissively or sarcastically, but there's any number of ways to say it that are…

I'm from California.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#392

Post by thaumasiotes » Sun, May 24, 2020, 8:08 PM UTC

dkersten wrote: post #342

thaumasiotes wrote: post #333

Earlier quoted context omitted.

"That's nice" is a way of explicitly stating that you don't care to any degree about whatever the other person just said.

What if it really is actually nice?

"How nice!" is a positive exclamation with minimal wording change from "that's nice".

You can also be explicit about who's being nice. "That's nice of you."

This really depends on what you want to mean by "nice".

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#393

Post by danielscrubs » Sun, May 24, 2020, 8:15 PM UTC

HelloNurse wrote: post #310

danielscrubs wrote: post #303

Earlier quoted context omitted.

Same in Swedish

Same in most languages, but there's also Emperor Mongo in Flash Gordon stories, definitely alluding to Mongol conquering hordes.

Most languages would be a stretch, there are over 7000 languages in the world.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#394

Post by erulabs » Sun, May 24, 2020, 9:35 PM UTC

kyberias wrote: post #283

erulabs wrote: post #273

Earlier quoted context omitted.

Yes, I couldn't agree more. Didn't mean people can't have opinions of course - just that they shouldn't be scoffing/laughing at tools - to me its a particularly red flag. Not wanting to use a particular tool is totally fine!

> just that they shouldn't be scoffing/laughing at tools Why on earth would that be a problem? Why are you sensitive about tools? Do the tools have feelings?

Tools are just tools. Imagine scoffing at someone using a hammer, when in your less experienced opinion, they should be using NewHammer3.1.

Tools are means to an end. I much prefer working with people who care about the product and the business than what tools they used to build said product/business. I'm looking for "hey, you could save a lot of time by using tool Y", rather than "You people are idiots for even considering tool Z".

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#395

Post by Hydraulix989 » Mon, May 25, 2020, 2:40 AM UTC

threeseed wrote: post #43

Hydraulix989 wrote: post #15

This has been a known issue for a while: https://hackingdistributed.com/2013/01/29/mongo-ft/ MongoDB: Broken By Design

Might want to read up as this involves a completely different set of issues. And most of those listed in the blog were fixed many years before 2013.

Actually, I read both articles. In fact, the author of the first article was my very own distributed systems professor in school. The persisting issue in both articles is a non rigorous specification of when a write actually completed. Both articles point out that a fault tolerant database should be ACID compliant, which does not live up to MongoDB’s claims.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#396

Post by Hydraulix989 » Mon, May 25, 2020, 2:42 AM UTC

Beefin wrote: post #108

Hydraulix989 wrote: post #15

This has been a known issue for a while: https://hackingdistributed.com/2013/01/29/mongo-ft/ MongoDB: Broken By Design

This is a good of the HN MDB hate: everything referenced has been addressed long before 2013. It was a new DB then and early adopters should know what they’re getting into

No. New doesn’t mean broken. Hyperdex was brand new at the time and still managed to be consistent with data.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#397

Post by mathattack » Mon, May 25, 2020, 4:15 AM UTC

macintux wrote: post #36

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…

The joke I learned early on: "Migrating away from Mongo is trivial: wait long enough, and all your data will be gone anyway." I imagine things are better now.

Let’s hope the data disappears after you’ve collected revenue but before you paid the expenses. Crap product, shady company, sleazeball salesforce.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#398

Post by mathattack » Mon, May 25, 2020, 4:17 AM UTC

square_usual wrote: post #228

kipply wrote: post #189

Earlier quoted context omitted.

Tangentially related their sales strategy is questionable. As an intern at Shopify, I got an email from MongoDB asking us to switch. Shopify was 10 years old the time. Plus several coworkers would also receive similar emails two years later (and some in between of course). I have a shirt from MemSQL that says "Friends don't let friends NoSQL" and I wear it proudly.

If their sales team is sending emails to interns, their strategy is very questionable indeed.

They will happily waste the time of anyone willing to take a call. They are so sleazy they make Oracle look clean.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#399

Post by mathattack » Mon, May 25, 2020, 4:20 AM UTC

naked-ferret wrote: post #5

From the jepsen report: """ Curiously, MongoDB omitted any mention of these findings in their MongoDB and Jepsen page. Instead, that page discusses only passing results, makes no mention of read or write concern, buries the actual report in a footnote, and goes on to claim: > MongoDB offers among the strongest data consistency, correctness, and safety guarantees of any database available today. We encourage MongoDB t…

Amazing that anyone can trust Mongo after this BS.

Re: Jepsen Disputes MongoDB's Data Consistency Claims

#400

Post by HelloNurse » Mon, May 25, 2020, 7:27 AM UTC

throwaway_pdp09 wrote: post #321

HelloNurse wrote: post #305

Earlier quoted context omitted.

Indirectly stating that they aren't good enough to use MongoDB properly could be offensive for thin-skinned developers, but it's only bad attitude. I'm much more concretely worried by a software design for which the authors (not hostile critics) consider "if you know what you are doing" an acceptable safety and quality standard for data integrity.

I've never used MongoDB and hopefully never will, but I have to defend that phrase in the larger context. A great number of programming problems I've seen have been to do with people not knowing what they're doing with complex tools, it really is that simple. Actual example: a long time ago someone in my company introduced a race condition into their product because they didn't know about transaction isolation levels…

Let's make an analogy. To drive a car one needs to "know what they are doing" to the point that driving licenses are mandatory. Let's consider a common accident type: a collision because you turn but your directional lights remain off.

If it happens because the driver just forgot to signal, it's a mistake and it's hard to blame the car. It's like knowing what transaction isolation levels can be used, but asking for the wrong one or trusting a random default.

On the other hand, if the directional lights remain off despite pulling the lever because the car is in a probably illegal power-saving mode, activated by turning the headlights off, and the driver should have reactivated directional lights with an ambiguously named item in the depths of some options menu, blaming the accident on user error would be very partisan: it's the car that doesn't know what it's doing. It's like figuring out the correct transaction isolation level according to DBMS documentation, asking for it, and expecting it is actually used.