[
https://issues.apache.org/jira/browse/BIGTOP-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787451#comment-13787451
]
Andrew Purtell edited comment on BIGTOP-993 at 10/6/13 1:56 AM:
----------------------------------------------------------------
bq. My understanding of the co-processors is that it is possible to load them
up from the HBase shell and I would imagine that it is how the Phoenix
implementation does it – from the client side
There are two ways to load a coprocessor - 'system coprocessors' are loaded
based on a setting in the HBase site file, and 'table coprocessors' are loaded
from a specification in table schema metadata. Table coprocessors are
dynamically loaded when the table is loaded and IIRC Phoenix uses these.
However, in both cases the coprocessor classes need to be on the classpath of
the regionserver, and this is constructed by the HBase binscript when the
daemon is launched. Actually, coprocessors can be loaded by URL, so could be
stored on HDFS, but I'm not sure I recommend that. And, Phoenix also uses
custom filters which cannot be loaded that way, those must be on the classpath.
bq. what are the chance of HBASE-8734 getting into HBase 0.96
There may not need be any changes beyond the binscripts. Such changes would be
minor and not change any existing functionality in an incompatible way, so I
don't see why not.
was (Author: apurtell):
bq. My understanding of the co-processors is that it is possible to load them
up from the HBase shell and I would imagine that it is how the Phoenix
implementation does it – from the client side
There are two ways to load a coprocessor - 'system coprocessors' are loaded
based on a setting in the HBase site file, and 'table coprocessors' are loaded
from a specification in table schema metadata. Table coprocessors are
dynamically loaded when the table is loaded and IIRC Phoenix uses these.
However, in both cases the coprocessor classes need to be on the classpath of
the regionserver, and this is constructed by the HBase binscript when the
daemon is launched.
bq. what are the chance of HBASE-8734 getting into HBase 0.96
There may not need be any changes beyond the binscripts. Such changes would be
minor and not change any existing functionality in an incompatible way, so I
don't see why not.
> Add packaging for Phoenix
> -------------------------
>
> Key: BIGTOP-993
> URL: https://issues.apache.org/jira/browse/BIGTOP-993
> Project: Bigtop
> Issue Type: Sub-task
> Affects Versions: 0.7.0
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Priority: Blocker
> Fix For: 0.7.0
>
> Attachments: 993.patch, 993.patch, 993.patch, 993.patch, 993.patch
>
>
> Phoenix (https://github.com/forcedotcom/phoenix) is an open source BSD-style
> licensed SQL skin over Apache HBase, delivered as a client-embedded JDBC
> driver. The Phoenix query engine transforms your SQL query into one or more
> HBase scans, and orchestrates their execution to produce standard JDBC result
> sets. Direct use of the HBase API, along with coprocessors and custom
> filters, results in performance on the order of milliseconds for small
> queries, or seconds for tens of millions of rows. Applications interact with
> Phoenix through a standard JDBC interface; all the usual interfaces are
> supported.
> As an enhancement of significant value to Apache HBase, in a Bigtop
> distribution Phoenix would have a role similar to that of Datafu, a
> collection of enhancements to Apache Pig.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
