hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mingjie Lai (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1512) Coprocessors: Support aggregate functions
Date Fri, 27 Aug 2010 07:19:54 GMT

    [ https://issues.apache.org/jira/browse/HBASE-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903275#action_12903275

Mingjie Lai commented on HBASE-1512:

Hi Himanshu. 

Right now I'm doing some cleanups for coprocessor. Here is the code: http://github.com/mlai/hbase.
Please use the branch -- coprocessors_mlai. 

However our current objective is to utilize CP to implement role based access control(RBAC)
toward 0.90. We only need Coprocessor, RegionObservor, CommandType interfaces for this purpose.
So I didn't include the MapReduce and FilterInterface in the branch (neither for 0.90 I think).

You can take a look at that branch. It can pass all HBase test cases, but we still need to
improve it a little for exception handling. 

If you have interests for Mapreduce implementation, you can also refer the first patch of


> Coprocessors: Support aggregate functions
> -----------------------------------------
>                 Key: HBASE-1512
>                 URL: https://issues.apache.org/jira/browse/HBASE-1512
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: stack
> Chatting with jgray and holstad at the kitchen table about counts, sums, and other aggregating
facility, facility generally where you want to calculate some meta info on your table, it
seems like it wouldn't be too hard making a filter type that could run a function server-side
and return the result ONLY of the aggregation or whatever.
> For example, say you just want to count rows, currently you scan, server returns all
data to client and count is done by client counting up row keys.  A bunch of time and resources
have been wasted returning data that we're not interested in.  With this new filter type,
the counting would be done server-side and then it would make up a new result that was the
count only (kinda like mysql when you ask it to count, it returns a 'table' with a count column
whose value is count of rows).   We could have it so the count was just done per region and
return that.  Or we could maybe make a small change in scanner too so that it aggregated the
per-region counts.  

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message