Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB