hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Stathis <gstat...@gmail.com>
Subject Re: Contrib tableindexed package vs. custom indexes
Date Wed, 31 Mar 2010 00:57:52 GMT
Stack, thanks for getting back to me. I think we are better off going with
the contrib approach and investing our dev time there. It will benefit
everyone in the long term, including us.

-GS

On Tue, Mar 30, 2010 at 2:04 PM, Stack <stack@duboce.net> wrote:

> Sorry George for lack of response.  I think it probably a bit of 3.)
> and then 4.) which is that you know cleanly the options so there is
> nothing really to add.
>
> My sense is that when fellas say roll your own indexes, between the
> lines I think what they are saying is that they do not want to do the
> two updates transactionally -- that they do not want to pay the
> ITHBase tax -- and are ok w/ losing a index add or two.
>
> The preso at ApacheCon was a callout to THBase and ITHBase recognizing
> that its been a contrib for a good while now and that perhaps its
> graduated beyond our designation of it as 'experimental'.
>
> St.Ack
>
>
> On Mon, Mar 29, 2010 at 12:51 PM, George Stathis <gstathis@gmail.com>
> wrote:
> > Hi folks,
> >
> > I've seen some people around the list that recommend rolling one's own
> > indexes. Others say to just go with
> > the org.apache.hadoop.hbase.client.tableindexed package. A quick scan of
> the
> > wiki does not reveal any best practices. Presentations from the devs such
> as
> > the Oakland ApacheCon slides point to the contrib package.
> >
> > Some of the comments in the list seem to note that IndexedTable is not
> very
> > performant; then again, I would assume that a custom index would have to
> > wrap any table+index operations in a transaction anyway. So unless folks
> > forego transactions when rolling their own indexes, I don't see how a
> custom
> > implementation could be that much faster.
> >
> > What do the majority of people here do for indexing? Is there a generally
> > accepted good middle-of-the-road approach offering an acceptable
> compromise
> > between performance and maintainability? I must admit that rolling our
> own
> > indexes does not seem like a viable long term approach to me (from a
> > maintenance POV).
> >
> > I'm interested in people's opinion.
> >
> > -GS
> >
>

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