hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George P. Stathis" <gstat...@traackr.com>
Subject Re: On 'routs' and traackr
Date Wed, 08 Feb 2012 19:49:39 GMT
On Wed, Feb 8, 2012 at 1:31 PM, 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.
>

Just to clarify this point: we were able to replace some MapReduce jobs we
had with straight MongoDB cursor iterator jobs (the equivalent of HBase
scanners basically) without slowing down the time it took for the jobs to
complete. What my post says is that this cursor approach may be outgrown at
some point as our data grows, not MongoDB as a whole. When/if that happens,
we have the option of using the available MongoDB / Hadoop
integration<https://github.com/mongodb/mongo-hadoop>
.

-GS



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message