[
https://issues.apache.org/jira/browse/HBASE-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242460#comment-13242460
]
Matt Corgan commented on HBASE-5674:
------------------------------------
I've been brainstorming something similar as a follow-on to HBASE-4676. The
more similar timestamps you have in a block, the smaller the encoded version.
Most people doing a simple, flat table with 1 version of each cell don't care
about the timestamps. They're only needed to pick the latest cell. If all
timestamps in an HFile are the same then they will encode down to nothing.
One possibility is to have an option "flattenTimestamps" where you grab
t=currentTimeMillis() at the beginning of a flush and overwrite all timestamps
with it. To support multiple versions of a cell, you could use t-1, t-2, etc
(as long as they don't go all the way back to the previous hfile's timestamp).
> add support in HBase to overwrite hbase timestamp to a version number during
> major compaction
> ---------------------------------------------------------------------------------------------
>
> Key: HBASE-5674
> URL: https://issues.apache.org/jira/browse/HBASE-5674
> Project: HBase
> Issue Type: Improvement
> Reporter: He Yongqiang
> Assignee: He Yongqiang
>
> Right now, a millisecond-level timestamp is attached to every record.
> In our case, we only need a version number (mostly it will be just zero etc).
> A millisecond timestamp is too heavy to carry. We should add support to
> overwrite it to zero during major compaction.
> KVs before major compaction will remain using system timestamp. And this
> should be configurable, so that we should not mess up if the hbase timestamp
> is specified by application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
