hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: On 'routs' and traackr
Date Thu, 09 Feb 2012 01:51:25 GMT
This reminds me a bit of Microsoft's old "Total TCO" studies of Linux. When your competitor
is a true open source product, not a "community" with a single commercial concern as owner/gatekeeper/dictator,
I guess lies, statistics, and benchmarks are the only refuge to hock your wares. We've been
around the block before with Hypertable Inc. This time the benchmark seems better designed,
but the HBase configuration used during testing remains a strawman. They don't seem to try
for fair comparisons, I suppose the goal is marketing.

This 'rout' plays to the confirmation bias of folks who prefer C++ to Java, or are suspicious
of the JVM, or resent the need for GC tuning in any realistic system. Given the prominence
of this superficiality, one can speculate that is the goal. I come from a C++ background.
Sometimes I hate the JVM. I fantasize about reimplementing the Hadoop ecosystem in C++ using
LLVM. Maybe someday I'll find the time to put together a pitch and some VC will sign on and
I'll kill Hadoop as we know it with a runaway success built on that awesomeness.

Seriously, a clear perspective is required when doing serious work. What one has is a different
set of 
tradeoffs. For sure the JVM gives HBase some pain (and other parts of the Hadoop ecosystem),
some tuning is necessary to avoid GC troubles. However, because we chose to use HBase (and
other parts of the Hadoop ecosystem) in production, we don't have to troubleshoot cluster
issues by firing up gdb to walk Hypertable master coredumps. In contrast the JVM has excellent
capabilities for introspection. And a hundred other such things...

Best regards,


    - Andy


Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)



----- Original Message -----
> From: Todd Lipcon <todd@cloudera.com>
> To: user@hbase.apache.org
> Cc: 
> Sent: Thursday, February 9, 2012 8:16 AM
> Subject: Re: On 'routs' and traackr
> 
> Regardless of Traackr or whatever mud/fud the Hypertable folks want to
> sling, let's not lose focus on what we're doing: building the most
> scalable, solid, data storage system out there.
> 
> It's nice to learn lessons from folks who have moved off of HBase or
> those who want to try to compete. But also keep in mind that though we
> might have lost one user, we've gained so many other much larger
> installs in the last year or two - I won't sweat the loss of a few
> people over to MongoDB. They'll always crush us on feature set, but
> we'll always crush them on so many other dimensions. We can't be all
> things to all people, so let's keep with what we're good at.
> 
> One nice anecdote: I recently gave a talk comparing HBase and Accumulo
> in which I tried to use one slide to show a comparison of community
> size and number of production deploys. I quickly ran out of space on
> the slide for all the logos of HBase users (while the other half of
> the slide had one nice big one).
> 
> Todd
> 
> On Wed, Feb 8, 2012 at 10:31 AM, Ted Yu <yuzhihong@gmail.com> wrote:
>>  I read the report from traackr where the author mentioned that the size of
>>  data may out grow MongoDB approach.
>> 
>>  I think we do need to make HBase more user friendly. This involves making
>>  setup easier, parameter tuning more dynamic (HBASE-5349, etc) and
>>  ultimately, adding secondary index support.
>> 
>>  Cheers
>> 
>>  On Wed, Feb 8, 2012 at 8:54 AM, Stack <stack@duboce.net> wrote:
>> 
>>>  The Hypertable crew are throwing stones again.  See
>>> 
>>> 
> http://highscalability.com/blog/2012/2/7/hypertable-routs-hbase-in-performance-test-hbase-overwhelmed.html
>>>  if you haven't already.  ("Shock! Horror!  Java App GCs when
>>>  misconfigured!").  J-D did a bit of a response.  We should do a
>>>  comparison some day (Volunteers?).   It seems like hypertable has some
>>>  nice ergonomics that we could pickup where it changes allocations
>>>  based on the incoming loading.  Its probably time too to look at
>>>  default tunings again so out of the box we run smooth when suites like
>>>  performance evaluation are set running.
>>> 
>>>  This article by George and the lads over at Traackr is more
>>>  interesting in my opinion:
>>> 
> http://traackr.com/blog/2012/02/traackrs-migration-from-hbase-to-mongodb/
>>>   There are reminders for us therein: e.g. some more attention to ease
>>>  of operation.  This is not news I know -- and our letting go of the
>>>  (unsatisfactory) built-in secondary indexing contrib left them a high
>>>  and dry (we could have done better messaging around these contribs it
>>>  seems) -- but nonetheless a timely reminder from the lads over at
>>>  Traackr (sorry to see you go George and crew).
>>> 
>>>  St.Ack
>>> 
> 
> 
> 
> -- 
> Todd Lipcon
> Software Engineer, Cloudera
> 

Mime
View raw message