hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Please help me overcome HBase's weaknesses
Date Sun, 05 Sep 2010 00:02:28 GMT
2010/9/4 MauMau <maumau307@gmail.com>:
> However, my boss points out the following as the weaknesses of HBase and
> insists that we choose Cassandra. I prefer HBase because HBase has stronger
> potential, thanks to its active community and rich ecosystem backed by the
> membership of Hadoop family. Are there any good explanations (or future
> improvement plans/ideas) to persuade him and change his mind?
>

What is the problem you are trying to solve?  That'll help figure if
hbase is suitable.


> (1) Ease of use
> Cassandra does not require any other software. All nodes of Cassandra have
> the same role. Pretty easy.
> On the other hand, HBase requires HDFS and ZooKeeper. Users have to
> manipulate and manage HDFS and ZooKeeper. The nodes in the cluster have
> various roles, and the users need to design the placement of different types
> of nodes.
>

Yes, in the 'ease of use' dept. we need to do some work.

But your boss seems rather to be criticizing the fact that our system
is made of components.  In software engineering, this is usually
considered a strength.  As to 'roles', one of the bigtable author's
argues that a cluster of master and slaves makes for simpler systems
[1].

If you have big data, you are running hadoop already?  If so, you
already have hdfs in place.  If you have big systems and are trying to
do HA, you'll have a zookeeper ensemble in place already or at least,
if you haven't, you are likely considering it?  In this case, HBase
complements your existing infrastructure?

Out of the box, HBase can manage zookeeper for you.  There is an issue
to make it so when 'start' hbase, by default it starts hdfs too.
Would that help?

I've tripped over blog posts where zookeeper is grafted to a cassandra
ensemble to add facility that is inherent to hbase; e.g. locks and
counters (though in the first case, zk is not suitable for cluster
locks and yes, I've also read of the patch to do counters using vector
clocks).


> (2) Failover time
> One of our potential customers requires that the system completes failover
> within one second. "One second" means the interval between when the system
> detects node failure and when the clients regain access to data.
> Cassandra continues to process requests if one of three replica nodes
> remains. Therefore, the requirement is met.
> However, HBase seems to take minutes, because it needs to reassign regions
> to live region servers, open reassigned regions and load their block index
> into memory, and perform log application. As the hardware gets more
> powerful, each node will be able to handle more regions. As a result,
> failover time will get longer in proportion to the number of regions, won't
> it?
> ## My question:
> Is it possible to improve failover time? If yes, how long will it get
> shortened?
> ##
>

While we working hard to tighten recovery times, without relaxing
consistency, I doubt we'll ever be able to recover in under 'one
second', not any time soon at least (There has been talk of being able
to come up in a manner where we could take on writes near immediately
after a crash and only later let in reads -- or relax consistency and
let in reads, but no work has been done yet).

> (3) SPOF
> Cassandra has no SPOF. HBase and future HDFS eliminates SPOF by using backup
> masters, however, master failure *can* the entire system operation in some
> way. How long does it take to detect master failure and make one of the
> backup masters promote to the new master and return to normal operation?
>

As Jon says, hbase master failure should be fast and besides, master
is not in the way of read/write path so should have no effect on
latencies.

Work is being done to federate the name node and there is the facebook
avatar namenode work to remove or mitigate the HDFS SPOF.

> (4) Storage and analysis of sensor data
> If the row key is (sensor_id) or (sensor_id, timestamp), Cassandra can hash
> the row key and distribute inserts from many sensors to the entire cluster
> (no hotspot). Though MapReduce framework may throw commands to all nodes,
> the nodes that do not have related data will not do anything nor waste CPU
> or I/O resources.
> ## My question:
> Is there any case study where HBase is used as a storage for sensor data?
> ##
>

Why can't you do the same in hbase?  Hash sensor_id + ts and have it
distributed across all of the cluster and have no 'hotspot'?

But rather, speak to an hbase strength; cells are versioned, by
default, by timestamp.  All sensor readings could be kept together so
summing or graphing over ranges will be returned faster by hbase and
w/o the need of consulting mulitiple nodes?

At stumbleupon we have a sensor database built on hbase.  Purportedly
its to be made open.  Watch this list for announcements.

St.Ack

1. See slide 52
http://www.slideshare.net/rawroot/jeffrey-dean-evolution-and-future-directions-of-large-scale-storage-and-computation-systems-at-google
Listen to the talk for more around this point.

Mime
View raw message