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

It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

blog.basho.com

Post reply on HN
Print view View original

31–40 of 67 posts

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#31

Post by tuna »

arihant wrote: post #28

We performed our own crash testing for a Riak and about a million other databases, Riak and MySQL with InnoDB were the only cases scoring more than 5 out of 10. I think the problem with NoSQL is that they are targeting the wrong people - the lazy people. One of the DBs we reviewed (can't remember which) did not have single datacentre durability, lost like 80% data while crash during updating table contents and was bo…

wait until you fill your mysql + innodb with real data, have a crash and have to perform a check to get it back online. stick with riak.

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#32

Post by batasrki »

ethangunderson wrote: post #25
batasrki wrote: post #23

Earlier quoted context omitted.

>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.

When we talk about consistency, we're talking about taking the database from one consistant state to another. With replica sets, we're still only dealing with one master. We can get inconsistant reads from the replicas, but we're always writing to a single master, which allows that master to determine the integrity of a write. With sharding, we're still only dealing with one canonical home for a specific key(defined…

None of this is guaranteed by default. By default, writes are flushed every 60 seconds. By default, there's no journaling. How can one claim full consistency if the the former two points are true?

Don't get me wrong, I love mongo. I'm building a web app backed by it. But the marketing talk is grating, which whT this post nails.

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#33

Post by benblack »

kchodorow wrote: post #29
batasrki wrote: post #23

Earlier quoted context omitted.

>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.

MongoDB is partition tolerant and consistent. You can never have multi-master with MongoDB, which is required for "always writable." However, it can be readable. Our CEO did a series of posts on distributed consistency, see http://blog.mongodb.org/post/475279604/on-distributed-consis... .

If a slave can continue serving reads whilst partitioned from a master that continues to accept writes then you cannot guarantee consistency. If a slave cannot serve reads when partitioned then you aren't available. If a master cannot accept writes when partitioned then you aren't available. See this excellent post from Coda Hale on why it is meaningless to claim a system is partition tolerant http://codahale.com/you-cant-sacrifice-partition-tolerance/.

One love.

- Lil' B

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#34

Post by mathias_10gen »

batasrki wrote: post #23
kchodorow wrote: post #22

Earlier quoted context omitted.

10gen doesn't publish any benchmarks. See http://www.mongodb.org/display/DOCS/Benchmarks for the official position. I transcribed the MongoDB vs. Riak part of the Changelog webcast (available at http://thechangelog.com/post/3742814720/episode-0-5-1-mongod... ): ------------------------ Riak and all the dynamo-style databases are really distributed key/value stores and I think, you know, I've never used Riak in produc…

>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.

In the sharded case, at any given moment each object will still live on exactly one replica set, which will have at most one master. You can do operations (such as findAndModify http://bit.ly/ilomQo) that require a "current" version of an object because all writes are always sent to the master for that object. You can also choose to accept a weaker form of consistency for some reads by directing them to slaves for performance. This decision can be made per-operation from most languages.

As for trade-offs: Relative to a relational db, there is no way to guarantee a consistent view of multiple objects because they could live on different servers which disagree about when "now" is. Relative to an eventually consistent system, you are unable to do writes if you can't contact the master or a majority of nodes are down.

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#35

Post by mathias_10gen »

batasrki wrote: post #32
ethangunderson wrote: post #25

Earlier quoted context omitted.

When we talk about consistency, we're talking about taking the database from one consistant state to another. With replica sets, we're still only dealing with one master. We can get inconsistant reads from the replicas, but we're always writing to a single master, which allows that master to determine the integrity of a write. With sharding, we're still only dealing with one canonical home for a specific key(defined…

None of this is guaranteed by default. By default, writes are flushed every 60 seconds. By default, there's no journaling. How can one claim full consistency if the the former two points are true? Don't get me wrong, I love mongo. I'm building a web app backed by it. But the marketing talk is grating, which whT this post nails.

I think those two issues are orthogonal to consistency. In ACID, consistency and durability are two different letters and CAP doesn't even mention durability. Are you referring to another definition of consistency?

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#36

Post by mshneider718 »

benblack wrote: post #30

To some commenters: the C in CAP and the C in ACID are not the same thing. If that is not clear to you, it is unlikely the database you develop will include correct implementations of core concepts. Knowledge is power. Peace and love to the human family. - Lil' B

Good point...CAP and ACID are not overlapping concepts - in fact, you kinda have to throw out ACID rules when you create a Dynamo-inspired data store

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#37

Post by roder »

mshneider718 wrote: post #36
benblack wrote: post #30

To some commenters: the C in CAP and the C in ACID are not the same thing. If that is not clear to you, it is unlikely the database you develop will include correct implementations of core concepts. Knowledge is power. Peace and love to the human family. - Lil' B

Good point...CAP and ACID are not overlapping concepts - in fact, you kinda have to throw out ACID rules when you create a Dynamo-inspired data store

Of course the opposite of ACID is BASE: http://queue.acm.org/detail.cfm?id=1394128

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#38

Post by alexpopescu »

mihasya wrote: post #24
batasrki wrote: post #23

Earlier quoted context omitted.

>Mongo is fully consistent Can you please explain this for a case where there are multiple replica sets, the database is sharded and nodes are across data centers? What's sacrificed? Something must be.

The implication is that the people for whom eventual consistency is not an option will never reach a data set size or availability requirement that'll require them to use replication and experience the lag (and eventual consistency) involved.

That's not completely true. Take a look at Google's Megastore paper: http://www.cidrdb.org/cidr2011/Papers/CIDR11_Paper32.pdf

James Hamilton has a good summary of the ideas in the paper: http://perspectives.mvdirona.com/2011/01/09/GoogleMegastoreT...

Re: It's Time to Drop the "F" Bomb - or "Lies, Damn Lies, and NoSQL."

#40

Post by spudlyo »

tuna wrote: post #31
arihant wrote: post #28

We performed our own crash testing for a Riak and about a million other databases, Riak and MySQL with InnoDB were the only cases scoring more than 5 out of 10. I think the problem with NoSQL is that they are targeting the wrong people - the lazy people. One of the DBs we reviewed (can't remember which) did not have single datacentre durability, lost like 80% data while crash during updating table contents and was bo…

wait until you fill your mysql + innodb with real data, have a crash and have to perform a check to get it back online. stick with riak.

You're confusing InnoDB with MyISAM. InnoDB does redo log recovery like all grown up databases. MyISAM requires a lengthy fsck type operation.
Post reply on HN