Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Re: [ANNOUNCE] Secondary Index in HBase - from Huawei

Copy link to this message
Re: [ANNOUNCE] Secondary Index in HBase - from Huawei
Michael, JOIN is not supported in Phoenix for very obvious reasons and will
probably never be (may be except of JOIN against replicated tables) .
On Wed, Aug 14, 2013 at 1:52 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> On Wed, Aug 14, 2013 at 8:45 AM, Michael Segel <[EMAIL PROTECTED]
> >wrote:
> > This isn't too bad if you're doing a simple query against one index. You
> > can do the work by RS and then join the results from all RS.
> >
> > However… what happens if you have two indexes and your result set is
> going
> > to be the intersection of the indexes?
> >
> > Or you're going to do a join between two tables using the indexes to
> limit
> > the result set?
> >
> > Now your design breaks down quickly.
> >
> You may have just described their design assumptions.
> I'm not endorsing this per se, but suggesting it is not a good idea on
> account it can't live up to the requirements of a pretty particular
> strawman seems a step too far.
> Maybe someone from Huawei can talk a bit here about successful use cases?
> > You could also look at Lucene which we did a PoC a few years back.
> A certain large technology company has an HBase full text index built on
> Lucene that might be offered as a contribution at some point. From what I
> know of it, there are a different set of tradeoffs and it certainly won't
> work for everyone, and not because the people working on it were not smart
> enough to find a silver bullet.
> --
> Best regards,
>    - Andy
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)