5 ms·

We use HBase pretty extensively and I have mixed feelings about it. On one hand, it's very clunky. Though the documentation is pretty good these days, setting u

by karterk 13y ago

We use HBase pretty extensively and I have mixed feelings about it. On one hand, it's very clunky. Though the documentation is pretty good these days, setting up and managing a HBase cluster on production and in scale involves tackling many moving parts. Setting up Cassandra is almost a joke in comparison. HBase-Hadoop integration is great, but Cassandra has caught up significantly on that front. If you want strong consistency, apart from HBase there is no other (non-sql) solution that's really battle tested. If you're okay with eventual consistency, you should take a hard look at Cassandra.

threeseed 13y ago
I don't understand why people keep thinking that Cassandra is only eventually consistent. It can be set to any consistency level you like for both reads and writes: http://www.datastax.com/docs/1.1/dml/data_consistency http://www.datastax.com/docs/1.1/dml/data_consistency
- jbellis 13y ago
  Even lightweight transactions in 2.0 for linearizability: http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0 http://www.datastax.com/dev/blog/lightweight-transactions-in...
- duaneb 13y ago
  It doesn't even have transactions, I'm not sure how 'consistency' is even in the conversation. EDIT: Just saying, failures and partitions are extremely difficult to deal with without atomic operations.
  - jbellis 13y ago
    Here we're discussing the Consistency in CAP, not the one in ACID. Here's a good introduction to the concepts involved: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html http://www.allthingsdistributed.com/2008/12/eventually_consi...
    - duaneb 13y ago
      It's no less applicable. During a partition (you know, the 'P' in CAP) it's a nightmare to identify data that's been dropped AND recover from it without strong transaction guarantees. Transactions are the heart of consistency and I wouldn't consider a piece of software to be CAP consistent as opposed to available without transactions.
- linuxhansl 13y ago
  And then you get slow writes and/or reads as multiple nodes need to be contacted, as well as temporary outages when a quorum cannot be formed.
  - jbellis 13y ago
    That's a pretty silly objection. With the common three replicas, I have to lose two Cassandra nodes to be unable to achieve quorum. I have to lose just one regionserver to be unable to read from HBase.
    - linuxhansl 13y ago
      The "silly" label is not productive. When we have R+W>N, and assuming N is 3, there is either a hit on read and write (W=R=2) or heavy hit on write (W=3, R=1) or heavy hit on read with a chance of temporary outages (W=1, R=3). In HBase you write to exactly one server and read from exactly one server, which also provides for cheap atomic operations.
- karterk 13y ago
  I'm aware of consistency levels. But in general HBase performs much better out of the box when compared to tweaking Cassandra to be be more consistent. In other words, if I wanted consistency badly and at scale, I would go with HBase.

by karterk 13y ago

threeseed 13y ago

I don't understand why people keep thinking that Cassandra is only eventually consistent. It can be set to any consistency level you like for both reads and writes: http://www.datastax.com/docs/1.1/dml/data_consistency http://www.datastax.com/docs/1.1/dml/data_consistency

jbellis 13y ago
Even lightweight transactions in 2.0 for linearizability: http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0 http://www.datastax.com/dev/blog/lightweight-transactions-in...
duaneb 13y ago
It doesn't even have transactions, I'm not sure how 'consistency' is even in the conversation. EDIT: Just saying, failures and partitions are extremely difficult to deal with without atomic operations.
- jbellis 13y ago
  Here we're discussing the Consistency in CAP, not the one in ACID. Here's a good introduction to the concepts involved: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html http://www.allthingsdistributed.com/2008/12/eventually_consi...
  - duaneb 13y ago
    It's no less applicable. During a partition (you know, the 'P' in CAP) it's a nightmare to identify data that's been dropped AND recover from it without strong transaction guarantees. Transactions are the heart of consistency and I wouldn't consider a piece of software to be CAP consistent as opposed to available without transactions.
linuxhansl 13y ago
And then you get slow writes and/or reads as multiple nodes need to be contacted, as well as temporary outages when a quorum cannot be formed.
- jbellis 13y ago
  That's a pretty silly objection. With the common three replicas, I have to lose two Cassandra nodes to be unable to achieve quorum. I have to lose just one regionserver to be unable to read from HBase.
  - linuxhansl 13y ago
    The "silly" label is not productive. When we have R+W>N, and assuming N is 3, there is either a hit on read and write (W=R=2) or heavy hit on write (W=3, R=1) or heavy hit on read with a chance of temporary outages (W=1, R=3). In HBase you write to exactly one server and read from exactly one server, which also provides for cheap atomic operations.
karterk 13y ago
I'm aware of consistency levels. But in general HBase performs much better out of the box when compared to tweaking Cassandra to be be more consistent. In other words, if I wanted consistency badly and at scale, I would go with HBase.