[jira] [Comment Edited] (BIGTOP-993) Add packaging for Phoenix

["Andrew Purtell (JIRA)" <ji...@apache.org>]

    [ 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)