3 ms·

Heavy HBase user here. My two cents, FWIW. I totally identify with both sides of this article, but if we had to do this again, we would probably go for HBase a

Heavy HBase user here. My two cents, FWIW. I totally identify with both sides of this article, but if we had to do this again, we would probably go for HBase again. Its quite a pain to manage unless you have someone on your team with a PhD in HBase, but: 1. The main HBase committers are also the ones who contribute to the Hadoop project, so its in a forward trajectory with good velocity, since its fairly coupled to the Hadoop ecosystem. Cloudera is a big contributor, as are Facebook and Salesforce. 2. Facebook, Adobe and other BigTM companies use it in production and at scale. (Granted they have armies of smart people to maintain HBase.) 3. For all the pain it is, its reasonably documented and has a growing community that fills in the gap. I could be totally totally wrong about this, but Cassandra doesn't have that same level of community as HBase does.

jbellis 13y ago
/author of the "con" position here I can see why you might come to those conclusions -- a lot of people with their heads down in Hadoop just don't realize that there's a world outside HDFS. Not saying that in a mean way; that's just the way it is. If you're involved in that ecosystem, there's enough to keep up with without researching what others are doing. 1. True enough, but HBase tends to be an afterthought for the datawarehouse-focused Hadoop players. You see this manifest in a bunch of ways, but as just one example: when I evaluated HBase at Rackspace 4 years ago, they were exploring options for secondary indexes. They're still exploring. 2. Yes, you really do have to have expert-level knowledge of the internals to deploy it successfully. And there's a LOT of those internals, by design (hmaster, ZK, regionserver, and close ties to the HDFS infrastructure). Cassandra is much simpler, much easier to deploy and troubleshoot. When Cassandra gets evaluated vs HBase, it tends to win [1], but often HBase is the "default" choice because of "Hey, we already have HDFS" thinking. This is changing as awareness grows of alternatives. 3. I think that's the tunnel vision I mentioned. By any metric I can think of -- conference attendance (over 1100 at the Cassandra Summit in June), IRC activity, StackOverflow participation, jobs advertised -- the Cassandra community is larger and more active than HBase's. Here's a list of some of the users: [2]. Give it a look, I'll be happy to answer questions! [1] http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf [2] http://planetcassandra.com/Company/ViewCompany?IndustryId=-1 http://planetcassandra.com/Company/ViewCompany?IndustryId=-1
- samspenc 13y ago
  Thanks for the reply! 1. True, the fact that we were deploying Hadoop was a big reason to go with HBase. Despite the challenges, it was a case of "better the devil we know than the one we don't." 2. Agreed, I played with Cassandra, but again, point #1 carried the day. 3. That's great! I was at HBaseCon 2013 and that only had 750-850 people. I concede this point. ;) Sorry I didn't explore this further, that was my bad. [EDIT] One thing we like is that HBase re-partitions data really fast since data is in HDFS. Not sure how well Cassandra holds up there.

jbellis 13y ago

/author of the "con" position here I can see why you might come to those conclusions -- a lot of people with their heads down in Hadoop just don't realize that there's a world outside HDFS. Not saying that in a mean way; that's just the way it is. If you're involved in that ecosystem, there's enough to keep up with without researching what others are doing. 1. True enough, but HBase tends to be an afterthought for the datawarehouse-focused Hadoop players. You see this manifest in a bunch of ways, but as just one example: when I evaluated HBase at Rackspace 4 years ago, they were exploring options for secondary indexes. They're still exploring. 2. Yes, you really do have to have expert-level knowledge of the internals to deploy it successfully. And there's a LOT of those internals, by design (hmaster, ZK, regionserver, and close ties to the HDFS infrastructure). Cassandra is much simpler, much easier to deploy and troubleshoot. When Cassandra gets evaluated vs HBase, it tends to win [1], but often HBase is the "default" choice because of "Hey, we already have HDFS" thinking. This is changing as awareness grows of alternatives. 3. I think that's the tunnel vision I mentioned. By any metric I can think of -- conference attendance (over 1100 at the Cassandra Summit in June), IRC activity, StackOverflow participation, jobs advertised -- the Cassandra community is larger and more active than HBase's. Here's a list of some of the users: [2]. Give it a look, I'll be happy to answer questions! [1] http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf [2] http://planetcassandra.com/Company/ViewCompany?IndustryId=-1 http://planetcassandra.com/Company/ViewCompany?IndustryId=-1

samspenc 13y ago
Thanks for the reply! 1. True, the fact that we were deploying Hadoop was a big reason to go with HBase. Despite the challenges, it was a case of "better the devil we know than the one we don't." 2. Agreed, I played with Cassandra, but again, point #1 carried the day. 3. That's great! I was at HBaseCon 2013 and that only had 750-850 people. I concede this point. ;) Sorry I didn't explore this further, that was my bad. [EDIT] One thing we like is that HBase re-partitions data really fast since data is in HDFS. Not sure how well Cassandra holds up there.