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

51–60 of 67 posts

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

#51

Post by haberman »

benblack wrote: post #43
haberman wrote: post #41

Earlier quoted context omitted.

> 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

That's deep man, but I posed an actual question.

BigTable (which I use daily and have extensive experience with) offers atomic and transactional updates at the row level. It uses Paxos to guarantee that at most one process at a time owns each row and can mutate it. That process keeps a sequential log that imposes an absolute order over updates to that row.

So it appears to me that despite being a NoSQL database, BigTable rows offer both ACID and the "C" of CAP. In fact, I bet it would be possible to implement a MySQL backend that uses a BigTable row as its storage.

I get strlen's point that C != C (it's more analogous to A/I), but my real point is that NoSQL (at least in the case of BigTable) doesn't appear to be fundamentally different than SQL in the offered guarantees, but rather in the granularity at which those guarantees are offered. NoSQL just takes the traditional one-single-ACID-entity model (a SQL database) and breaks it apart into lots of little ACID entities called rows/keys/documents/etc.

CAP of course applies to both SQL and NoSQL equally.

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

#52

Post by aguynamedben »

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…

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

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

#53

Post by haberman »

benblack wrote: post #43
haberman wrote: post #41

Earlier quoted context omitted.

> 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

ps. no need to sign your comments here: http://ycombinator.com/newsguidelines.html

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

#54

Post by mnutt »

mmalone wrote: post #15

Credit where credit's due, the 10gen and MongoDB guys have done a great job convincing developers to adopt their product despite the existence of technically superior alternatives. I guess that's what happens when a bunch of ex-DoubleClick execs start a database company.

"ex-DoubleClick exec" gives the image of some kind of ad executive or something, which is not what Dwight is.

http://www.10gen.com/video/mongosv2010/replication

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

#55

Post by mmalone »

haberman wrote: post #51
benblack wrote: post #43

Earlier quoted context omitted.

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

That's deep man, but I posed an actual question. BigTable (which I use daily and have extensive experience with) offers atomic and transactional updates at the row level. It uses Paxos to guarantee that at most one process at a time owns each row and can mutate it. That process keeps a sequential log that imposes an absolute order over updates to that row. So it appears to me that despite being a NoSQL database, BigT…

BigTable enforces integrity constraints defined by a schema on a per-row basis? This is interesting news. Why hasn't Google included this information in any of the published materials describing the system?

- Forever Malone

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

#56

Post by benblack »

haberman wrote: post #51
benblack wrote: post #43

Earlier quoted context omitted.

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

That's deep man, but I posed an actual question. BigTable (which I use daily and have extensive experience with) offers atomic and transactional updates at the row level. It uses Paxos to guarantee that at most one process at a time owns each row and can mutate it. That process keeps a sequential log that imposes an absolute order over updates to that row. So it appears to me that despite being a NoSQL database, BigT…

I was not aware that BigTable worked that way, but it doesn't change my original point about "C != C". That a given NoSQL system is architected for both does not imply that such a design is always desirable or representative of the NoSQL database space. It is not and it is not. Thank you for your kind and compassionate suggestions about signing comments.

- Lil' B

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

#57

Post by haberman »

mmalone wrote: post #55
haberman wrote: post #51

Earlier quoted context omitted.

That's deep man, but I posed an actual question. BigTable (which I use daily and have extensive experience with) offers atomic and transactional updates at the row level. It uses Paxos to guarantee that at most one process at a time owns each row and can mutate it. That process keeps a sequential log that imposes an absolute order over updates to that row. So it appears to me that despite being a NoSQL database, BigT…

BigTable enforces integrity constraints defined by a schema on a per-row basis? This is interesting news. Why hasn't Google included this information in any of the published materials describing the system? - Forever Malone

What about this story is inspiring people to write smarmy comments and sign them with silly pseudonyms?

Bigtable itself doesn't provide a schema or constraints, but it provides primitives that would allow you to implement them AFAICS. That's why I mentioned the idea of implementing a MySQL backend that uses BigTable as its storage -- MySQL would contain the schema and constraint logic, BigTable would provide the sequentially-consistent data storage.

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

#58

Post by tuna »

spudlyo wrote: post #40
tuna wrote: post #31

Earlier quoted context omitted.

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.

you are confusing real world with a comment on hackernews. try and do a full recovery on innodb with real data and get back so uncle tuna can hold you tight and promise that will never happen again. hint: corrupted tables crashing mysql processes and you having to start it with innodb_recovery 4 for ro, dumping the table, reapplying it back.

-- Mel Gibson's surgeon on "Payback"

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

#59

Post by tuna »

Also, a word about Consistency:

“There’ll be a time when all people are alike.” “Which is precisely the ideal society. No mysteries, no romantics, no discussions, no persecution because there’s no one to persecute. When all have received the same conditioning, it will be like…” “Insects.” “Who have existed longer than ourselves and will outlast our race by many millennia.” “Is existence everything? “There’s nothing else.”

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

#60

Post by tuna »

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…

Which C is lying ? CEO or CAP ? I let to the heart of pure and to the late night sysadmin to decide.
Post reply on HN