3 ms·

As Jonathan has pointed out, the article has lots of inaccuracies, but it also has a very good explanation of the NoSQL Faustian pact: "Cassandra doesn't do jo

As Jonathan has pointed out, the article has lots of inaccuracies, but it also has a very good explanation of the NoSQL Faustian pact: "Cassandra doesn't do joins... doesn't guarantee referential integrity, where the user knows the data being used reflects the latest updates... can't process transactions, with a guarantee that the transaction will either be completed or discarded, the way relational systems do" because it focuses on "more immediate goals than the pristine data handling rules of relational systems." As the expression goes: at the poker table, if you don't know who the sucker is, it's you. Guess who's responsible for those fuddy-duddy, old-fashioned things like querying your data, or making sure that you've written data, or that your database isn't corrupted... it's you. If you're Twitter, and you're fail-whaling every day, then maybe the work required to make this trade-off work makes sense. But I can't help but feel there's got to be a better way.

raganwald 17y ago
I won't defend Cassandra's design choices here, but I will say that the relational model is only about joins and normal forms. The other things you mention happen to be built into all modern relational databases but are orthogonal concepts. A distributed hash table can be built with transactions, isolation, and so forth. Such a system would offer a different set of trade-offs that might satisfy a different set of users.
- justinsb 17y ago
  Completely agree with you on the theoretical level; it's a (lazy) shorthand to contrast the typical NoSQL trade-offs with the ACID model that most relational databases employ. In practice though, I think if you introduce (multi-'row') ACID into any of today's NoSQL database, you'd just end up with a bad traditional database (a 'relational' database without a strong theoretical grounding, without the ability to do joins and without a powerful query language.) This whole NoSQL movement feels like a re-run of the evolution of the relational database - those that don't know their history are doomed to repeat it.
  - jbellis 17y ago
    > I think if you introduce (multi-'row') ACID into any of today's NoSQL database, you'd just end up with a bad traditional database Strongly disagree, although there is truth to the converse (adding sharding to a traditional database yields a bad nosql implementation :). There's a sketch of how Google added multirow transactions to bigtable for app engine (via a layer above bigtable called megastore): http://perspectives.mvdirona.com/2008/07/10/GoogleMegastore.aspx http://perspectives.mvdirona.com/2008/07/10/GoogleMegastore.... The key idea is that "a per-entity-group transaction log is used. One of the rows that stores the entity group is the entity group’s root. The log is stored with the root, which is replicated like all rows in Big Table." This is basically a version of the approach advocated by Pat Helland in his paper on "Life Beyond Distributed Transactions" -- http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf -- namely, that the most sane approach to distributed transactions is to redefine the problem, and restrict transactions to be within "entities" that fit on a single machine. Which, as App Engine demonstrates, turns out to be enough to do an awful lot.
    - cx01 17y ago
      > Strongly disagree Would you mind explaining why you disagree? > the most sane approach to distributed transactions is to redefine the problem, and restrict transactions to be within "entities" that fit on a single machine. How is disallowing distributed transactions a sane approach? There's no harm in allowing distributed transactions using 2PC and letting the developer decide if he wants to incur the performance penalty or wants to colocate the data-structures to the same node to avoid 2PC overhead.
    - jbellis 17y ago
      [replying to cx01] > Would you mind explaining why you disagree? I did, that's what the rest of the comment is. :) > How is disallowing distributed transactions a sane approach? That's the subject of Pat's entire paper, which I linked.
    - justinsb 17y ago
      Interesting links - thanks. There's definitely a continuum here - the full ACID model at one end; key-value stores at the other. It looks like Google is moving in the right direction - adding more ACID - which certainly plays to my personal bias :-)

raganwald 17y ago

I won't defend Cassandra's design choices here, but I will say that the relational model is only about joins and normal forms. The other things you mention happen to be built into all modern relational databases but are orthogonal concepts. A distributed hash table can be built with transactions, isolation, and so forth. Such a system would offer a different set of trade-offs that might satisfy a different set of users.

justinsb 17y ago
Completely agree with you on the theoretical level; it's a (lazy) shorthand to contrast the typical NoSQL trade-offs with the ACID model that most relational databases employ. In practice though, I think if you introduce (multi-'row') ACID into any of today's NoSQL database, you'd just end up with a bad traditional database (a 'relational' database without a strong theoretical grounding, without the ability to do joins and without a powerful query language.) This whole NoSQL movement feels like a re-run of the evolution of the relational database - those that don't know their history are doomed to repeat it.
- jbellis 17y ago
  > I think if you introduce (multi-'row') ACID into any of today's NoSQL database, you'd just end up with a bad traditional database Strongly disagree, although there is truth to the converse (adding sharding to a traditional database yields a bad nosql implementation :). There's a sketch of how Google added multirow transactions to bigtable for app engine (via a layer above bigtable called megastore): http://perspectives.mvdirona.com/2008/07/10/GoogleMegastore.aspx http://perspectives.mvdirona.com/2008/07/10/GoogleMegastore.... The key idea is that "a per-entity-group transaction log is used. One of the rows that stores the entity group is the entity group’s root. The log is stored with the root, which is replicated like all rows in Big Table." This is basically a version of the approach advocated by Pat Helland in his paper on "Life Beyond Distributed Transactions" -- http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf http://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf -- namely, that the most sane approach to distributed transactions is to redefine the problem, and restrict transactions to be within "entities" that fit on a single machine. Which, as App Engine demonstrates, turns out to be enough to do an awful lot.
  - cx01 17y ago
    > Strongly disagree Would you mind explaining why you disagree? > the most sane approach to distributed transactions is to redefine the problem, and restrict transactions to be within "entities" that fit on a single machine. How is disallowing distributed transactions a sane approach? There's no harm in allowing distributed transactions using 2PC and letting the developer decide if he wants to incur the performance penalty or wants to colocate the data-structures to the same node to avoid 2PC overhead.
  - jbellis 17y ago
    [replying to cx01] > Would you mind explaining why you disagree? I did, that's what the rest of the comment is. :) > How is disallowing distributed transactions a sane approach? That's the subject of Pat's entire paper, which I linked.
  - justinsb 17y ago
    Interesting links - thanks. There's definitely a continuum here - the full ACID model at one end; key-value stores at the other. It looks like Google is moving in the right direction - adding more ACID - which certainly plays to my personal bias :-)