hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3162) Add TimeRange support into Increment to optimize for counters that are partitioned on time
Date Thu, 28 Oct 2010 06:32:07 GMT

    [ https://issues.apache.org/jira/browse/HBASE-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925712#action_12925712
] 

Todd Lipcon commented on HBASE-3162:
------------------------------------

In terms of API design, I dont have any great ideas, but I think a general pattern that we
might be able to use across HBase is to use "builder-style" mutations rather than just overloading
"increment()" with a bunch of different parameter choices.

For example, a potential API might look like:

{code}
Increment i = new Increment("rowkey")
  .incrementColumn("foo", 1)
  .incrementColumn("bar", 2) // for multi-column increment
  .withPredicate(
    new TimeRangeFilter(startTimestamp, stopTimestamp));
htable.doMutation(i);
{code}

This style of API might be able to collapse some of the code between Get, Put, Delete, checkAndPut,
Filters, etc.

> Add TimeRange support into Increment to optimize for counters that are partitioned on
time
> ------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3162
>                 URL: https://issues.apache.org/jira/browse/HBASE-3162
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, regionserver
>    Affects Versions: 0.90.0
>            Reporter: Jonathan Gray
>            Priority: Minor
>
> In many use cases of increments, a given counter is only incremented during a specific
window of time (ie. the counters are partitioned/sharded by time).
> With this kind of schema, you are constantly creating new counters.  When a new counter
is "created" (incremented the first time) you will always end up looking at a block from every
file in the region because no previous value will exist.  However, with the new TimeRange
optimizations that skip files if they don't contain values of the TimeRange you're interested
in, we could utilize that information to optimize the Get within the increment.
> This would be optional and an addition to the Increment class.

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


Mime
View raw message