[
https://issues.apache.org/jira/browse/HBASE-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242850#comment-13242850
]
Scott Chen commented on HBASE-5674:
-----------------------------------
> Can you not just have your client specify timestamp of 0?
We still need the timestamp when the write was happening for versioning.
But after major compaction we don't need the exact timestamp.
We only need to know it's version is old.
The timestamp takes 8 bytes for every column.
And the last digits of these timestamps are very random so it cannot be
compressed well.
In our tests, the space it consumed can be quite significant.
I believe in a lot of use cases, these millisecond resolution timestamp may not
be useful after compaction.
It will be nice to have the ability to remove them to save some spaces.
> 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
