Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Big Data Debate: HBase

informationweek.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Big Data Debate: HBase

#41

Post by duaneb »

threeseed wrote: post #24
karterk wrote: post #23

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 c…

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

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.

Re: Big Data Debate: HBase

#42

Post by e12e »

duaneb wrote: post #4

NoSQL is my least favorite buzzword of the decade. It means absolutely nothing but being counter cultural to... SQL culture. Many NoSQL "databases"—and I use that in the lightest term possible—even have SQL engines.

I prefer the (backronym?) Not Only SQL - as it better describes what NOSQL can help with -- as opposed to using only a normalized relational data store.

Re: Big Data Debate: HBase

#43

Post by monstrado »

duaneb wrote: post #38
monstrado wrote: post #35

Earlier quoted context omitted.

HBase doesn't claim to be some NoSQL database or equivalent to a relational database, anyone who thinks otherwise hasn't actually read into HBase. Just look at HBase's website which describe it exactly as > Apache HBase is the Hadoop database, a distributed, scalable, big data store.

I mean, I understand this, but plenty of people identify it as NoSQL. I'm sure the people on HBase are intelligent enough to understand it's a meaningless phrase that would make them look silly. EDIT: By which I mean, "NoSQL" doesn't even make sense as an approach by name. ACID relational databases and high availability data stores both have their places so evangelizing on either side is just silly. Though I would li…

True, but there's no way to avoid people interpreting NoSQL as a relational database alternative.

To your point regarding Google's F1, try looking at Impala (https://github.com/cloudera/impala)...

Re: Big Data Debate: HBase

#44

Post by linuxhansl »

threeseed wrote: post #24
karterk wrote: post #23

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 c…

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

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.

Re: Big Data Debate: HBase

#45

Post by jbellis »

samspenc wrote: post #39

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 t…

/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 [2] http://planetcassandra.com/Company/ViewCompany?IndustryId=-1

Re: Big Data Debate: HBase

#46

Post by jbellis »

duaneb wrote: post #41
threeseed wrote: post #24

Earlier quoted context omitted.

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

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

Re: Big Data Debate: HBase

#47

Post by jbellis »

linuxhansl wrote: post #44
threeseed wrote: post #24

Earlier quoted context omitted.

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

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.

Re: Big Data Debate: HBase

#48

Post by jbellis »

mh- wrote: post #36
threeseed wrote: post #26

Earlier quoted context omitted.

I don't know about HBase but for Cassandra it should be available in the next minor update. Single row transactions have just recently been added: http://www.datastax.com/dev/blog/lightweight-transactions-in...

FWIW, Cassandra 1.2 is the latest production/stable version.

You are correct, for about another week. :)

Re: Big Data Debate: HBase

#49

Post by duaneb »

jbellis wrote: post #46
duaneb wrote: post #41

Earlier quoted context omitted.

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.

Re: Big Data Debate: HBase

#50

Post by dialtone »

linuxhansl wrote: post #40

Oh please. On the one side we have a commercially competing entity arguing against HBase and on the other side we have an individual "defending" HBase who never contributed a single line of code to open source HBase promoting their own closed source solution. HBase is a "Sparse, Consistent, Distributed, Multidimensional, Sorted map" and at that it is pretty good. Other stores are either not consistent or not sorted b…

Agreed. Out of the box none of the other storage systems actually allow you to not worry about range scans at all. While HBase will repartition your data to balance the used disk space automatically, in most other systems you'll end up having to manually partition your data in different ways and then aggregate the queries across partitions.

This is pretty literally the main reason why many companies use HBase. Then in the same companies you can also find a good usage for Cassandra but it'd be a different use case.

Post reply on HN