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

41–50 of 67 posts

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

#41

Post by haberman »

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

> To some commenters: the C in CAP and the C in ACID are not the same thing.

This is an interesting point, but I wonder if they are really that different. Even NoSQL systems support atomic updates and sequential consistency at some granularity (like a single key, document, etc.)

I wonder if it's really so inaccurate to think of NoSQL data stores as a set of tiny ACID databases, one for each key/document/etc.

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

#42

Post by strlen »

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

Just to expand on this, the "C" in CAP corresponds (roughly) to the "A" and "I" in ACID. Atomicity across multiple nodes requires consensus. According to FLP Impossibility Result (CAP is a very elegant and intuitive re-statement of FLP), consensus is impossible in a network that may drop or deliver packets. Serializable isolation level requires that operations are totally ordered: total ordering on multiple nodes, requires solving the "atomic multicast" problem which is a private instance of the general consensus problem.

In practice, you can achieve consensus across multiple nodes with a reasonable amount of fault tolerance if you are willing to accept high (as in, hundreds of milliseconds) latency bounds. That's a loss of availability that's not acceptable to many applications.

This means, that you can't build a low-latency multi-master system that achieves the "A" and "I" guarantees. Thus, distributed systems that wish to achieve a greater form of consistency typically (Megastore from Google being a notable exception, at the cost of 140ms latency) choose master slave systems (with "floating masters" for fault tolerance). In these systems availability is lost for a short period of time in case the master fails. BigTable (or HBase) is an example of this: (grand simplification follows) when a tablet master (RegionServer in HBase) for a specific token range fails, availability is lost until other nodes take over the "master-less" token range.

These are not binary "on/off" switches: see Yahoo's PNUTS for a great "middle of the road" system. The paper http://research.yahoo.com/node/2304 > has an intuitive example explaining the various consistency models.

Note: in a partitioned system, the scope of consistency guarantees (that is, any consistency guarantees: eventual or not) is typically limited to (at best) a single partition of a "table group"/"entity group" (in Microsoft Azure Cloud SQL Server and Google Megastore, respectively), a single partition of a table (usual sharded MySQL setups) or just a single row in a table (BigTable) or document in a document oriented store. Atomic and isolated cross row transactions are impractical on commodity hardware (and are limited even in systems that mandate the use of infiband interconnect and high-performance SSDs).

[Disclaimer: I am commiter on Project Voldemort, a Dynamo implementation; in addition to Dynamo, I also find Yahoo's PNUTS and Google's BigTable to be very interesting architectures.]

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

#43

Post by benblack »

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

> To some commenters: the C in CAP and the C in ACID are not the same thing. This is an interesting point, but I wonder if they are really that different. Even NoSQL systems support atomic updates and sequential consistency at some granularity (like a single key, document, etc.) I wonder if it's really so inaccurate to think of NoSQL data stores as a set of tiny ACID databases, one for each key/document/etc.

They really are that different, and I hear 10gen is hiring. Increase the peace.

- Lil' B

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

#44

Post by jorgeortiz85 »

benblack wrote: post #33
kchodorow wrote: post #29

Earlier quoted context omitted.

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…

In a replica set configuration, all reads and writes are routed to the master by default. In this scenario, consistency is guaranteed. (You can optionally mark reads as "slaveOk", but then you admit inconsistency.)

This does sacrifice availability (in the CAP sense), but I haven't heard anyone claim otherwise.

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

#45

Post by benblack »

strlen wrote: post #42
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

Just to expand on this, the "C" in CAP corresponds (roughly) to the "A" and "I" in ACID. Atomicity across multiple nodes requires consensus. According to FLP Impossibility Result (CAP is a very elegant and intuitive re-statement of FLP), consensus is impossible in a network that may drop or deliver packets. Serializable isolation level requires that operations are totally ordered: total ordering on multiple nodes, re…

Thanks for bringing some much needed science to these proceedings, my man. Too many people mistaking computer science for a therapy session where their feelings matter. Computer science has much in common with the honey badger. Think upon this and be enlightened.

Yours in perpetual discovery, - Lil' B

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

#46

Post by batasrki »

mathias_10gen wrote: post #35
batasrki wrote: post #32

Earlier quoted context omitted.

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?

How is flushing a write every 60 seconds orthogonal to consistency? If there's a server crash between the write to RAM and the subsequent flush, the data is lost, is it not? How do you guarantee the data is there in that case?

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

#47

Post by mihasya »

alexpopescu wrote: post #38
mihasya wrote: post #24

Earlier quoted context omitted.

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...

think you're viewing my statement out of the necessary context..

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

#49

Post by strlen »

coffeemug wrote: post #39

You can't escape the laws of physics, but if you know how to get physics on your side you can do things that at first glance appear impossible. See: human flight.

Practical, heavier than air flight was made possible due to internal combustion engines. It's also still less practical and more expensive for some applications e.g., cargo than other options. Practical, low-latency distributed databases based on "invoke consensus protocol on every commit to the log" would be made possible (on limited size local networks) when networking gear with performance exceeding 10GigE/Infiniband becomes "commodity". Even then, it will still be impractical and too expensive for some scenarios.

At the present time, the fact that I said "invoke consensus on every commit to the log" and "low latency" in the same sentence is making distributed systems engineers cringe (I would _not_ advocate building such a system). The fact that I said "Infiniband" and commodity in the same sentence is also making systems administrators and DBAs cringe.

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

#50

Post by [deleted] »

benblack wrote: post #45
strlen wrote: post #42

Earlier quoted context omitted.

Just to expand on this, the "C" in CAP corresponds (roughly) to the "A" and "I" in ACID. Atomicity across multiple nodes requires consensus. According to FLP Impossibility Result (CAP is a very elegant and intuitive re-statement of FLP), consensus is impossible in a network that may drop or deliver packets. Serializable isolation level requires that operations are totally ordered: total ordering on multiple nodes, re…

Thanks for bringing some much needed science to these proceedings, my man. Too many people mistaking computer science for a therapy session where their feelings matter. Computer science has much in common with the honey badger. Think upon this and be enlightened. Yours in perpetual discovery, - Lil' B

[deleted]
Post reply on HN