[
https://issues.apache.org/jira/browse/HBASE-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925717#action_12925717
]
ryan rawson commented on HBASE-3162:
------------------------------------
That doesn't address the real problem... how to expand the data transport in
a sane manner, how to deal with it internally etc. The builder stuff is just
semantic sugar. We currently hurt due to lack of a system like protobufs.
https://issues.apache.org/jira/browse/HBASE-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925712#action_12925712]
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.
Put, Delete, checkAndPut, Filters, etc.
partitioned on time
------------------------------------------------------------------------------------------
during a specific window of time (ie. the counters are partitioned/sharded
by time).
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.
> 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.
