hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Finding on HBase-Hypertable comparison
Date Sun, 29 Aug 2010 00:59:36 GMT
Thanks for writing the list Gagandeep.

See below.

On Thu, Aug 26, 2010 at 11:59 AM, Gagandeep Singh
<gagandeep.singh@paxcel.net> wrote:
> I found following shortcomings in HBase
> 1. Slower or equal in performance when compared with Hypertable. All my
> tests were ran over a DB schema where I interact with multiple tables with
> multiple column families and with multiple columns.

We'll fix this.  We've been focused on other things at the moment;
stability, scaling, data durability, and features necessary to a
production deploy such as replication, master failover, etc.

> 2. HBase Shell syntax is really difficult to adapt for someone coming from
> SQL background. Unfortunately most of the users will come from SQL
> background. Here I recall the success story of firefox Mozilla. They became
> a success because they have not changed the menu options in the browser and
> kept it as close to IE because they knew from where they were going to get
> their users.

We have the current shell -- ruby's irb with a few domain specific
verbs added -- because we wanted to bolt an already-built, rich shell
to hbase rather than spend time developing one ourselves. irb was also
attractive because it was *not* SQL.   A previous SQL-like shell was
jettisoned because it misled users into thinking hbase a SQL-store,
something you could hook your crystal reports to or attach a jdbc
driver.  This shell turned farcical when the developer wanted to
initiate mapreduce jobs from the shell to satisfy certain SQL queries
which you sort of need when tables get big dumping and loading, or
saving big selects aside, etc., but running mapreduce from the shell
was just perverse.  Committers were also spending way too much time
explaining what we were not, that though a users intro to hbase was
SQL-like, that in fact we were not a SQL store at all (The latter
SQL-like shell was also poorly implemented frustrating users and
supporting committers.  See http://www.hbql.com/ for a recent, much
better take -- with a shell too).

So we went out of our way to be not-SQL-like.

> Best things about HBase
> 1. Stable, I never got a crash when performing any operation even under very
> High load tests whereas Hypertable is unstable. Even their new releases are
> not up to the mark. I can understand that both communities are open source
> and evolving so such things can happen.
> 2. Much easier and better documented API's.
> 3. UI interface to see logs and many other important information.
> 4. Support for Gangila which makes life easy for people like us who needs to
> monitor DB and Machine performances.

There are the differentiating attributes Todd mentions -- some of
which are hard to come by -- but there are also other features we have
-- and that we've had for a long time now -- that HT does not have
such as auto-recovery of crashed servers and auto basic region
balancing.  For example, adding a server to an hbase cluster you just
start it and it'll pick up load.  In HT, "[f]or now, to increase the
size of your cluster, backup your tables, expand the size of your
cluster, and then restore from backup" [1].

Something that HT has that we do not is t-shirts [2].  Hopefully this
will not be held against us.

Thanks again for writing this list Gagan,

1. http://groups.google.com/group/hypertable-user/browse_thread/thread/59ed9b82a1ae06be?pli=1
2. http://blog.hypertable.com/?p=67

View raw message