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

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

#61

Post by jdefarge » Thu, May 12, 2011, 1:39 AM UTC

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…

Oh, great! Here we go again with that CAP flame war. In spite of strlen's well written post, things always degenerate in a pointless discussion everytime CAP is cited (Godwin, right?)

The truth is so simple: some applications can give up milliseconds (even hours) of "A" for strong "C" (but not otherwise), some apps can give up strong "C" for high "A" (but not otherwise). How difficult it is to accept this?

The tricky part is when to give up "C" or "A", where to draw the lines. There's no ready recipe for this, sorry. Basho post seems to point right into that direction when it states that it will provide various options across the CAP spectrum. Smart companies deliver what their customers want.

"But the world is eventual consistent then you always should choose A". Classic non sequitur. Yes, real world is weakly consistent, fractal and uncertain, but we, as computer professionals, aim to build models (i.e., simplifications) of real world processes. Now, try to model and automate all that uncertainty and inconsistency of the world when the deadlines are just around the corner!

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

#62

Post by benblack » Thu, May 12, 2011, 2:12 AM UTC

jorgeortiz85 wrote: post #44

benblack wrote: post #33

Earlier quoted context omitted.

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.

"In a replica set configuration, all reads and writes are routed to the master by default. In this scenario, consistency is guaranteed."

One would hope that reading and writing a single node database was consistent. This is table stakes for something calling itself a persistent store. Claiming partition tolerance in the above is the same as claiming availability. The former claim has been made. Rest left as exercise for the reader.

Namasté.

- Lil' B

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

#63

Post by jdefarge » Thu, May 12, 2011, 2:22 AM UTC

aguynamedben wrote: post #52

benblack wrote: post #33

Earlier quoted context omitted.

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…

Lil' B, stop trying to outsmart us all, MongoDB works, supports JSON, and autoshards.

Thanks God. At least it's not Cassandra. :)

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

#64

Post by stonemetal » Thu, May 12, 2011, 2:58 AM UTC

batasrki wrote: post #46

mathias_10gen wrote: post #35

Earlier quoted context omitted.

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?

That would mean the data set was not durable, it doesn't speak to consistency at all. DB consistency is about transaction ordering. Transaction 1 always comes before transaction 2, but 2 may exist or not as it pleases. Transaction 1 must be present if 2 is present.

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

#65

Post by kchodorow » Thu, May 12, 2011, 2:14 PM UTC

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…

I interpreted "what is sacrificed?" as asking which letter of CAP MongoDB was giving up. Coda's article actually explains exactly the tradeoffs MongoDB makes for CP:

-------------------

Choosing Consistency Over Availability

If a system chooses to provide Consistency over Availability in the presence of partitions (again, read: failures), it will preserve the guarantees of its atomic reads and writes by refusing to respond to some requests. It may decide to shut down entirely (like the clients of a single-node data store), refuse writes (like Two-Phase Commit), or only respond to reads and writes for pieces of data whose "master" node is inside the partition component (like Membase).

This is perfectly reasonable. There are plenty of things (atomic counters, for one) which are made much easier (or even possible) by strongly consistent systems. They are a perfectly valid type of tool for satisfying a particular set of business requirements.

-------------------

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

#66

Post by jorgeortiz85 » Thu, May 12, 2011, 3:06 PM UTC

benblack wrote: post #62

jorgeortiz85 wrote: post #44

Earlier quoted context omitted.

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.

"In a replica set configuration, all reads and writes are routed to the master by default. In this scenario, consistency is guaranteed." One would hope that reading and writing a single node database was consistent. This is table stakes for something calling itself a persistent store. Claiming partition tolerance in the above is the same as claiming availability. The former claim has been made. Rest left as exercise…

If a slave is partitioned from its master, it won't be able to serve requests. (Unless the request is a read query marked as "slaveOk", in which case you admit inconsistency.) I highly doubt anyone would claim otherwise.

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

#67

Post by alnayyir » Fri, May 13, 2011, 2:44 AM UTC

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

Stop signing your posts.