2010/9/4 MauMau <[email protected]>: > 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.
