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

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


+
Andrew Purtell 2013-08-13, 18:31
+
Michael Segel 2013-08-14, 15:45
+
Vladimir Rodionov 2013-08-14, 16:40
+
Michael Segel 2013-08-14, 19:53
+
Andrew Purtell 2013-08-14, 20:52
+
Michael Segel 2013-08-14, 23:17
+
Vladimir Rodionov 2013-08-14, 21:04
+
Ted Yu 2013-08-14, 21:12
+
Michael Segel 2013-08-14, 23:19
Copy link to this message
-
Re: [ANNOUNCE] Secondary Index in HBase - from Huawei
James Taylor 2013-08-14, 21:18
True, JOIN is not yet supported in Phoenix.

However, we are working on supporting joins, starting with hash joins that
are equi-joins where one side of the join is small enough to fit into
memory. See https://github.com/forcedotcom/phoenix/issues/20 for more
information.

Thanks,
James
On Wed, Aug 14, 2013 at 2:12 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> bq. JOIN is not supported in Phoenix
>
> That is correct.
>
> See https://github.com/forcedotcom/Phoenix/wiki
>
> On Wed, Aug 14, 2013 at 2:04 PM, Vladimir Rodionov
> <[EMAIL PROTECTED]>wrote:
>
> > 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)
> > >
> >
>
+
lars hofhansl 2013-08-14, 22:35
+
Michael Segel 2013-08-14, 23:57
+
lars hofhansl 2013-08-15, 01:10
+
Michael Segel 2013-08-15, 03:08
+
Anoop John 2013-08-13, 06:44
+
ramkrishna vasudevan 2013-08-13, 07:28
+
Nicolas Liochon 2013-08-13, 06:47
+
Jesse Yates 2013-08-13, 06:51
+
zhoushuaifeng 2013-08-18, 15:06