[
https://issues.apache.org/jira/browse/HBASE-11315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052729#comment-14052729
]
stack commented on HBASE-11315:
-------------------------------
On commit:
Rename + long getSeqId(); as getSequenceId. Give it its full name. No
ambiguity. Yes, this is a better name for this method now what we record here
has changed. Suggest also pointing at getSequenceId from deprecation message
in getMvccVersion.
6 days is just odd. Make it 7 so its a week? Or go back to 5 (the 'working'
week -- smile).
+ /** At least to keep MVCC values in hfiles for 6 days */
+ public static final int MIN_KEEP_SEQID_PERIOD = 6;
In KV, do setSequenceId instead of setSeqId. Why not have getMvccVersion call
getSequenceId instead of presuming it always will return this.seqid? Who knows?
Should we change mvcc here:
+ "/vlen="
+ + getValueLength() + "/mvcc=" + seqId;
Could be seqid here I'd say or sid.
We'll have to have another JIRA to change memstoreTs variable name? (Thats
fine... just saying)
+ public long getSeqId() {
+ return memstoreTS;
Is it original or source? Would source_sequence_number be better name? Maybe
original is better.... It conveys that this edit came via recovery....
+ optional uint64 orig_sequence_number = 11;
Change this to getReplaySequenceId:
+ public long getReplaySeqId() {
No longer needed?
- // For the optimisation in HBASE-4346, we set the KV's memstoreTS to
- // 0, if it is older than all the scanners' read points. It is possible
- // that a newer KV's memstoreTS was reset to 0. But, there is an
- // older KV which was not reset to 0 (because it was
- // not old enough during flush). Make sure that we set it correctly now,
- // so that the comparision order does not change.
- if (cur.getMvccVersion() <= readPt) {
- KeyValueUtil.ensureKeyValue(cur).setMvccVersion(0);
- }
Otherwise, looks great. +1
> Keeping MVCC for configurable longer time
> ------------------------------------------
>
> Key: HBASE-11315
> URL: https://issues.apache.org/jira/browse/HBASE-11315
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.99.0
> Reporter: Jeffrey Zhong
> Assignee: Jeffrey Zhong
> Attachments: hbase-11315-v1.patch, hbase-11315.patch
>
>
> After hbase-8763, we need keep mvcc number longer in hfile so that it can be
> used to order changes during writes. For example, the known
> put,delete,put,... scenario, cross region server scan, out of order puts(in
> recovery case).
> Current thinking is that we make the retention period configurable(below
> we're using 1 day to explain). During major compaction, we check hfile's
> creation time if a hfile creation time is older than 1 day then all mvcc of
> KVs in that hfile will be removed. If a hfile is created within 1 day, then
> all mvccs of KVs in that hfile will be kept.
> In case there are time clock skew, we can firstly sort hfiles based on its
> seqId in ascending order and find the first hfile's creation time stamp less
> than 1 day. Then mvcc of all hfiles before the found file will be removed
> during compaction.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
