[
https://issues.apache.org/jira/browse/HBASE-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979729#action_12979729
]
stack commented on HBASE-3434:
------------------------------
@Dhruba Tell us more what attributes this 'new record' type will look like?
How will it differ from plain cell? Will the cell be marked in some manner if
its an aggregation of all behind it? The server will know to stop looking once
it runs up against such a rollup point? Will rollups be done in background or
on a read?
A KeyCollection is made of KVs? If not, what are its atoms? Or its a special
version of a KV (We have a Type field in KVs so we might be able to add in a
Collection type --- or List or Counter type if thats what we really want). To
get a view on a Collection, we'd have to fetch all mentions of a particular
'Collection' back as far as the last Collection 'tombstone' instance then roll
it all up to present the current view?
Good stuff Dhruba.
> ability to increment a counter without reading original value from storage
> --------------------------------------------------------------------------
>
> Key: HBASE-3434
> URL: https://issues.apache.org/jira/browse/HBASE-3434
> Project: HBase
> Issue Type: Improvement
> Components: client, regionserver
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
>
> There are a bunch of applications that do read-modify-write operations on
> HBase constructs, e.g a counter; The counter value has to be read in from
> hdfs before it can be incremented. We have an application where the number
> of increments on a counter far outnumbers the number of times the counter is
> used or read. For these type of applications, it will be very beneficial to
> not have to read in the counter from disk before it can be incremented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
