Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Call Me Maybe: MongoDB Stale Reads

aphyr.com

Post reply on HN
Print view View original

31–40 of 150 posts

Re: Call Me Maybe: MongoDB Stale Reads

#31

Post by jdcryans »

cpks wrote: post #16

People really underestimate the value of Occasional Consistency. Occasionally Consistent databases, like MongoDB, are great for approximation algorithms, sublinear time algorithms, and similar applications.

The issue isn't that MongoDB is eventually consistent, it's that the documentation claims that in some cases it's strictly consistent[1] while Kyle found that:

"MongoDB, even at the strongest consistency levels, allows reads to see old values of documents or even values that never should have been written."

1. http://docs.mongodb.org/manual/reference/glossary/#term-stri...

Re: Call Me Maybe: MongoDB Stale Reads

#33

Post by zapov »

tracker1 wrote: post #29
ak4g wrote: post #18

Earlier quoted context omitted.

Um, this is the postgres article: https://aphyr.com/posts/282-call-me-maybe-postgres There were no acknowledged writes lost. The only unacked-but-successful writes resulted from a connection while a commit ack was in-flight. That doesn't qualify as a data-consistency error, it means the client has to check if the data is present after reconnecting. But in no cases would the client reconnect to find that there were ac…

Now try it again with PostgreSQL's built in sharding or replication functionality... oh, wait.

The parent post correctly pointed out that including Postgres in that list is misleading at least.

Re: Call Me Maybe: MongoDB Stale Reads

#34

Post by josephg »

aidanhs wrote: post #22
jxf wrote: post #17

Earlier quoted context omitted.

That island of safety is a rapidly shrinking one. Jepsen covers more ground with each new post from Kyle. :)

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://techcrunch.com/2015/03/24/apple-acquires-durable-data...

Re: Call Me Maybe: MongoDB Stale Reads

#36

Post by threeseed »

ak4g wrote: post #18
threeseed wrote: post #9

Earlier quoted context omitted.

Actually the broader lesson would be to assume the worst in your application layer and try and remediate/verify wherever possible. If you look at his articles: Redis, PostgreSQL, Cassandra, ElasticSearch etc all had data consistency errors. And none of those have vendors making any claims. It's pretty sobering to say the least.

Um, this is the postgres article: https://aphyr.com/posts/282-call-me-maybe-postgres There were no acknowledged writes lost. The only unacked-but-successful writes resulted from a connection while a commit ack was in-flight. That doesn't qualify as a data-consistency error, it means the client has to check if the data is present after reconnecting. But in no cases would the client reconnect to find that there were ac…

I was talking about data consistency more broadly. "However, two writes (215 and 218) succeeded, even though they threw an exception claiming that a failure occurred". This obviously isn't ideal behaviour from the perspective of a developer but isn't necessarily not correct.

My broader point was that you need to assume the worst from your database in the application layer. Which I think you missed.

Re: Call Me Maybe: MongoDB Stale Reads

#38

Post by threeseed »

narrator wrote: post #27

I knew something was funny with Mongo when all the api calls defaulted to writes not being guaranteed to sync to disk. Maybe for a use case like aggregate statistics gathering it would be ok to risk missing a few updates in a crash for the sake of speed, but to make that the default??

You know this configuration change was changed in November 2012.

Do you think it's still relevant to be bringing this up ?

Re: Call Me Maybe: MongoDB Stale Reads

#39

Post by meritt »

addisonj wrote: post #28

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…

After MongoDB published their write speed benchmarks based entirely on unacknowledged writes (e.g. how fast can you write to a socket?), it's been a long downhill ride with an immense amount of inexplicable ignorant support.

Re: Call Me Maybe: MongoDB Stale Reads

#40

Post by hendzen »

meritt wrote: post #39
addisonj wrote: post #28

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…

After MongoDB published their write speed benchmarks based entirely on unacknowledged writes (e.g. how fast can you write to a socket?), it's been a long downhill ride with an immense amount of inexplicable ignorant support.

Can you post a link to these unacknowledged write benchmarks? I can't find them.
Post reply on HN