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

51–56 of 56 posts

Re: Big Data Debate: HBase

#51

Post by linuxhansl »

jbellis wrote: post #47
linuxhansl wrote: post #44

Earlier quoted context omitted.

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.

Re: Big Data Debate: HBase

#52

Post by karterk »

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

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.

Re: Big Data Debate: HBase

#53

Post by PaulHoule »

monstrado wrote: post #10
PaulHoule wrote: post #5

I laugh at mongodb, but every time I've seen a shootout between Hbase and Cassandra, Cassandra has won.

Could you please elaborate? It totally depends on use case...

(1) I've seen more than one project failure involving mongodb,

(2) Every time I've done a performance/features shootout of mongodb vs. other projects, mongodb doesn't just lose, it comes back with two black eyes.

Re: Big Data Debate: HBase

#54

Post by samspenc »

jbellis wrote: post #45
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 th…

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.

Re: Big Data Debate: HBase

#55

Post by duaneb »

monstrado wrote: post #43
duaneb wrote: post #38

Earlier quoted context omitted.

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

It's quite interesting to compare the two approaches, thanks for the tip. I mentioned it not because of the SQL but because of its unusual construction: it's a relational database stored on top of a (admittedly ACID) NoSQL (it actually does have a sql engine) key-value store: it's a full-blown relational database system where you don't have to worry about sharding. I think Impala also has a great approach to this, but I'd say it's far more similar to Dremel in that it's structurally still Key-Value. This, again, could be good or bad: probably easier to develop with but harder for the query planner to plan without the hints provided by a table-and-index based system. (i.e. possible—that would basically be F1—but you'd have to do it by hand).
Post reply on HN