Live data from Hacker News

Call Me Maybe: MongoDB Stale Reads

aphyr.com

81–90 of 150 posts

Re: Call Me Maybe: MongoDB Stale Reads

#81
post #41

Earlier quoted context omitted.

Actually, just use Riak. Those people know distributed bases. https://aphyr.com/posts/285-call-me-maybe-riak Now I hear they support consistency as well.

I think at one point the employees of Basho knew how to write distributed DBs - Riak is the most advanced AP DB from a distributed systems theory perspective. However, in recent months, their CEO, CTO and Chief Architect have left, as well as many of their prominent engineers. Worryingly, the new CTO seems content to make inane comments about "Data Gravity" [0]. [0] - http://www.kdnuggets.com/2015/03/interview-dave-m…

I think Riak's theory is fine, but theory isn't enough. And they may have succumbed to the Osborne effect with Riak 2.0.

Here's what I mean. Think of all the nice things you expect to come out of Riak's theoretical basis -- bulletproof distributed writes, for example.

Well, the default last-write-wins writes aren't bulletproof. They clearly fail Jepsen [1]. And if you turned off last-write-wins, then you'd have to handle siblings -- and how you were supposed to handle them without introducing inconsistency was quite unspecified. Riak clients gave you no help there.

Or, as the Jepsen article says, you could use CRDTs. Before 2.0, Riak had exactly one CRDT, the counter.

Something that might be appealing to some is built-in MapReduce. On the forums, people would warn you not to actually use it unless you didn't actually want availability after all. I don't know if they ever sorted that out.

Another supposedly nice thing was Riak Search. A distributed DB with full-text search out of the box -- that sounds great, right? But there were two things called Riak Search, and the first one just plain didn't work. They deprecated it before it had a replacement, but the replacement was supposed to come in 2.0.

So, Osborne effect. When people gradually discovered that Riak 1.x was bad, and the response was "but Riak 2.0 will be great!", that's a great reason not to use 1.x. 2.0 took a very, very long time, enough time for customers and potential customers, including us, to find other solutions.

[1] https://aphyr.com/posts/285-call-me-maybe-riak

Re: Call Me Maybe: MongoDB Stale Reads

#82
post #34
post #22

Earlier quoted context omitted.

Has there been any CP system passing a call-me-maybe test first time apart from Zookeeper [1]? [1] https://aphyr.com/posts/291-call-me-maybe-zookeeper

FoundationDB. Kyle didn't bother running Jepsen against FDB because foundationdb's internal testing was much more rigorous that Jepsen. The foundationdb team ran it themselves and it passed with flying colors: http://blog.foundationdb.com/call-me-maybe-foundationdb-vs-j... Sadly, fdb has been bought by Apple[1], and you can't download it anymore. I sincerely hope foundationdb gets opensourced or something. [1] http:/…

I believe the real reason was that FDB was not open sourced.

Jepsen tests cannot be used to prove the system is safe, but to prove it isn't.

It looks like very often he looks into source code in order to figure out how the system operates, that way he can find weaknesses and write test to his testing framework to demonstrate the issue.

I wouldn't trust any company that uses Jepsen to show that their product is safe.

Re: Call Me Maybe: MongoDB Stale Reads

#83
post #4

If you are a database author and you get a bug report from Kyle, spend a long time thinking about it before closing the issue as invalid.

Especially since many people will judge the competence of the engineering based on the response. It really makes me nervous when a database company doesn't even understand the problem for many days and then pretends like it's expected behavior afterwards even though it flies in the face of their documentation, advertising, and tech talks.

Re: Call Me Maybe: MongoDB Stale Reads

#84

Earlier quoted context omitted.

Postgres can survive a network partition? I wasn't aware that master-master or sharding+replication was in the box yet?

Did you read the article? It's not about PostgreSQL in a distributed setup: > Even though the Postgres server is always consistent, the distributed system composed of the server and client together may not be consistent. It’s possible for the client and server to disagree about whether or not a transaction took place.

To me that's not surprising. If the client connection drops, you might not know whether the transaction committed or not... the only way to know is to reconnect and inspect to see what happened.

If you want to avoid that kind of problem, use 2PC.

Do you (or the author) see this as a bug, or just something that might surprise people who haven't thought through the guarantees?

Re: Call Me Maybe: MongoDB Stale Reads

#85

Mongo absolutely nailed creating a database that is easy to get started with and even do things that are traditionally more 'hard' such as replication. It is still super attractive for me to pick it up for small projects, even after dealing with its (many) pain points both in development and operational settings. Given this, it is so tragic to see how dismissive they have been in regards to the consistency issues tha…

The reason why Mongo was able to "solve" those hard replication problems is because they simply ignored all those hard parts. That's the reason why Mongo is not reliable and most likely never will. The issues they have are due to fundamental design choices.

Re: Call Me Maybe: MongoDB Stale Reads

#88
post #86

This article is too technically advanced for me. As a casual MongoDB user, how do these problems affect me?

At several points real world scenarios are described, so just skim ahead to those.

Users could end up seeing private information in each others' accounts, for example.

Re: Call Me Maybe: MongoDB Stale Reads

#89
So what should users of MongoDB do? I'm asking because it is the main database used in Meteor and I'm very interested in Meteor.

Should the general advice just be "store in MongoDB everything that doesn't require consistency and use Postgresql for everything else"?

Re: Call Me Maybe: MongoDB Stale Reads

#90
post #86

This article is too technically advanced for me. As a casual MongoDB user, how do these problems affect me?

In very rare cases, you could see confirmed writes being rolled back, or reads returning data from before a confirmed write

How these problems will actually affect you depend on your applications. It could for example allow 2 users to be created with the same email address

Post reply on HN