[
https://issues.apache.org/jira/browse/HBASE-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861777#comment-16861777
]
stack commented on HBASE-21476:
-------------------------------
Hey [~timoha]. Took a look at the one-pager.
+ I like idea of Clock instead of EEdge.
+ In your reading, getting nano from Instant is always increasing or would we
have to do our own Clock (I seem to remember getting System.nanos was
susceptible to going backwards being the time at the local CPU -- but I may
just be remembering this wrong. Long time since looked at this).
+ Feature then is for branch-2+ only given it depends on jdk8.
+ You read the Hybrid Logical Clocks stuff I presume given you cite this as a
path toward it. I ask just to make sure you have that as background dev'ing
this feature.
+ The caveats seem fine to me around this feature.
I can help w/ modifying the yetus personality to run tests as per Sean's
suggestion above. Also, would like to help address the issues Sean raises above
w/ this feature coming in.
I took a quick scan of the patch.
+ Not important but maybe we can make this cheaper... (for later)
49 Instant now = Instant.now();
50 return now.getEpochSecond() * 1000000000 + now.getNano();
i.e. no object creation (would have to look at impls).
+ nit: looking at the change to requestMobCompaction method, doesn't
TableDescriptor have the list of ColumnDescriptors? You could do w/ one less
param here and elsewhere in your change.
+ nit: private final boolean isNanosecondTimestamps; ... the data member should
be called nanosecondeTimestamps... no 'is'. 'isNano... is name of method to
query this data member...
+ If making a new patch , 1000000 could be a define... (I kept wanting to
suggest left shift but that won't work... )
... did about half the patch.. Will be back.
> Support for nanosecond timestamps
> ---------------------------------
>
> Key: HBASE-21476
> URL: https://issues.apache.org/jira/browse/HBASE-21476
> Project: HBase
> Issue Type: New Feature
> Affects Versions: 2.1.1
> Reporter: Andrey Elenskiy
> Assignee: Andrey Elenskiy
> Priority: Major
> Labels: features, patch
> Attachments: Apache HBase - Nanosecond Timestamps v1.pdf,
> HBASE-21476.branch-2.1.0003.patch, HBASE-21476.branch-2.1.0004.patch,
> nanosecond_timestamps_v1.patch, nanosecond_timestamps_v2.patch
>
>
> Introducing a new table attribute "NANOSECOND_TIMESTAMPS" to tell HBase to
> handle timestamps with nanosecond precision. This is useful for applications
> that timestamp updates at the source with nanoseconds and still want features
> like column family TTL and "hbase.hstore.time.to.purge.deletes" to work.
> The attribute should be specified either on new tables or on existing tables
> which have timestamps only with nanosecond precision. There's no migration
> from milliseconds to nanoseconds for already existing tables. We could add
> this migration as part of compaction if you think that would be useful, but
> that would obviously make the change more complex.
> I've added a new EnvironmentEdge method "currentTimeNano()" that uses
> [java.time.Instant|https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html]
> to get time in nanoseconds which means it will only work with Java 8. The
> idea is to gradually replace all places where "EnvironmentEdge.currentTime()"
> is used to have HBase working purely with nanoseconds (which is a
> prerequisite for HBASE-14070). Also, I've refactored ScanInfo and
> PartitionedMobCompactor to expect TableDescriptor as an argument which makes
> code a little cleaner and easier to extend.
> Couple more points:
> - column family TTL (specified in seconds) and
> "hbase.hstore.time.to.purge.deletes" (specified in milliseconds) options
> don't need to be changed, those are adjusted automatically.
> - Per cell TTL needs to be scaled by clients accordingly after
> "NANOSECOND_TIMESTAMPS" table attribute is specified.
> Looking for everyone's feedback to know if that's a worthwhile direction.
> Will add more comprehensive tests in a later patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
