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

141–150 of 150 posts

Re: Call Me Maybe: MongoDB Stale Reads

#141

Post by siculars »

rspeer wrote: post #81
iconfluence wrote: post #46

Earlier quoted context omitted.

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 ha…

Ya, you have to handle siblings if you don't use LWW. If you would rather Riak execute a pre-defined merge strategy, use Riak's CRDT features.

The original Riak Search in vs 1.x was replaced with integrated Solr in Riak 2.x, and it works.

I'd love to hear more about your use case. Contact info in profile. I'm this username in all the usual suspects.

Disclaimer: I work at Basho.

Re: Call Me Maybe: MongoDB Stale Reads

#142

Post by siculars »

scurvy wrote: post #56
iconfluence wrote: post #46

Earlier quoted context omitted.

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…

Indeed. We're evaluating Riak CS and Swift. In a vacuum, I'd choose Riak CS any day. Knowing all of the drama at Basho, we're in a holding pattern at best and leaning (reluctantly) towards Swift. Basho needs to sell damn fast or just call it a day and open source the enterprise version.

The drama has died down. Drama is generally isolated to pitched battles amongst engineers for feature implementations ;)

Contact info in profile, this username at all the usual suspects.

Disclaimer: I work for Basho.

Re: Call Me Maybe: MongoDB Stale Reads

#143

Post by siculars »

kokey wrote: post #103
iconfluence wrote: post #46

Earlier quoted context omitted.

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 had a bad experience with riak v2. I think something went quite wrong in the process when going from v1 to v2, especially around Riak Search.

Riak Search in v1.x and Riak Search in v2.x are completely different. Riak 2.x tightly integrats Solr.

If you wanna talk about it I'm this username at all the usual online places.

Disclaimer: I work for Basho

Re: Call Me Maybe: MongoDB Stale Reads

#144

Post by siculars »

rdtsc wrote: post #41
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.

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.

We now offer a strong consistency option.

I'm this username in the usual places online if you wanna talk about it.

Disclaimer: I work for Basho

Re: Call Me Maybe: MongoDB Stale Reads

#145

Post by nazka »

coolgeek wrote: post #139
nazka wrote: post #136

Earlier quoted context omitted.

Same thing. I was a software dev, then I went to the back end with MongoDB and NodeJS, and I learnt what ACID means... Also about MySQL, many people forget it isn't ACID compliant either and just look at benchmarks or use MySQL "because Facebook uses it". I am sure that if any startup would use PostgreSQL it would avoid many problems on the road.

I think that PostgreSQL is, in almost every aspect, a superior product to MySQL. But MySQL not being ACID compliant is flat out wrong (assuming that you're using InnoDB)

Yes with InnoDB it is.

Re: Call Me Maybe: MongoDB Stale Reads

#146

Post by scurvy »

jodah wrote: post #60
scurvy wrote: post #56

Earlier quoted context omitted.

Indeed. We're evaluating Riak CS and Swift. In a vacuum, I'd choose Riak CS any day. Knowing all of the drama at Basho, we're in a holding pattern at best and leaning (reluctantly) towards Swift. Basho needs to sell damn fast or just call it a day and open source the enterprise version.

Drama aside, Riak and Swift are not in the same league.

Riak CS is. I said Riak CS, not Riak.

Re: Call Me Maybe: MongoDB Stale Reads

#147

Post by throwaway832975 »

tel wrote: post #104
GordyMD wrote: post #101

Earlier quoted context omitted.

> Jepsen cannot prove that your software is safe, only prove that it isn't. This doesn't just apply to Jepsen but to all software tests. You only ever test a finite set of scenarios, so you can't really ever guarantee your software is 'safe'/bug-free - only that it does not fail in common/expected scenarios.

Depending on how large "software tests" is in your mind this can easily be not the case. Kyle often mentions the tool TLA+ which enables complete and total formal analysis of certain systems. This can be a test which is complete and therefore a positive proof of correctness. It's also not difficult to test smaller components of your system if you note that the state space here is small enough to be exhausted. This is…

I don't know of any case in industry where TLA+ has been used to prove a spec correct. AFAIK it's only been used for model checking. Read the "Formal Methods at AWS" paper for details.

Re: Call Me Maybe: MongoDB Stale Reads

#148

Post by threeseed »

cpks wrote: post #99
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.

You misunderstand the results. PostgreSQL behaves as expected, and indeed, the only way it can behave. That's the Two General's Problem ( http://en.wikipedia.org/wiki/Two_Generals%27_Problem ). There is no way to solve it. PostgreSQL does as well as theoretically possible. I understand you lost data with Oracle and Teradata. 1. Most big corporate vendors do not have systems which are very well designed. (1) The sale…

> the reason you lost data is because you didn't know what you were doing

Missed this reply and thought it was funny. I work for one of the world's largest retailers and we are one of both Oracle's and Teradata's most loved customers. We have 4 Teradata DBAs provided BY Teradata amongst a team of 20 SQL Developers. We aren't messing around.

What YOU don't seem to understand is that bugs in your database can cause data loss. ACID or Strong Consistency will not save you.

Re: Call Me Maybe: MongoDB Stale Reads

#149

Post by cpks »

threeseed wrote: post #148
cpks wrote: post #99

Earlier quoted context omitted.

You misunderstand the results. PostgreSQL behaves as expected, and indeed, the only way it can behave. That's the Two General's Problem ( http://en.wikipedia.org/wiki/Two_Generals%27_Problem ). There is no way to solve it. PostgreSQL does as well as theoretically possible. I understand you lost data with Oracle and Teradata. 1. Most big corporate vendors do not have systems which are very well designed. (1) The sale…

> the reason you lost data is because you didn't know what you were doing Missed this reply and thought it was funny. I work for one of the world's largest retailers and we are one of both Oracle's and Teradata's most loved customers. We have 4 Teradata DBAs provided BY Teradata amongst a team of 20 SQL Developers. We aren't messing around. What YOU don't seem to understand is that bugs in your database can cause dat…

That's not exactly the sort of team where you'd expect MIT Ph.Ds to work. It's precisely big teams of mediocre people who run into issues based on not knowing exactly what the database is doing and how it's supposed to work that lead to data corruption due to misuse. It's almost always a boring problem (e.g. retail business software). It's almost always a clunky commercial "enterprise" solution (e.g. Oracle). It's almost always a big team. I'm not sure if I even need to go into application engineers -- you put your best and brightest into the core product, and solutions typically gets those that can't quite cut it there.

Regardless, your comment was about PostgreSQL, not Oracle. Oracle is a giant piece of software written by a corporation with over 100,000 employees. Something like that is bound to have bugs, and it has bugs indeed. Data corruption with Oracle certainly happens. PostgreSQL is written by a small, ultra-elite team. It's a much smaller codebase, so an expert developer can understand how the whole system works. There's a big difference in robustness between the two.

Of course database bugs can cause corruption. I've certainly had MonogDB eat my data. But the level of robustness of different databases is very different. There are many databases which are essentially bug-free. If you're losing data with PostgreSQL, odds are you're the one losing the data, not PostgreSQL.

Re: Call Me Maybe: MongoDB Stale Reads

#150

Post by [deleted] »

ivanb wrote: post #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"?

[deleted]
Post reply on HN