Hacker News Reader

Comment by karterk | Hacker News Reader

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.

View on HN

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

Even lightweight transactions in 2.0 for linearizability: http://www.datastax.com/dev/blog/lightweight-transactions-in...

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.

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com