[
https://issues.apache.org/jira/browse/HBASE-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925704#action_12925704
]
Jonathan Gray commented on HBASE-3162:
--------------------------------------
Couldn't agree more, Todd. That's my issue with this :)
I actually think it will be fairly utilized by more power users. I guess the
first question is whether it should be in the API or not.
If not, then we'd have to add some kind of non-API but documented set of
configurable options.
In this particular case, it's fairly simple to add TimeRange since we use it
for reads. I was planning on just documenting the heck out of the API javadoc
but I'm open to ideas on how to get advanced stuff in and not polluting core
APIs.
> 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.
