[
https://issues.apache.org/jira/browse/HBASE-21476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16709331#comment-16709331
]
Andrey Elenskiy commented on HBASE-21476:
-----------------------------------------
> Is there any way we could make this a hard enforcement? Maybe a new optional
> way to flag that a client write has been done using nanoseconds?
Yea, it would be useful as most developers probably look up code snippets
online to talk to HBase and I can see someone ending up providing milliseconds
even if they created table with NANOSECOND_TIMESTAMPS attribute. However, I
don't think it's possible to do this 100% reliably. One way is to make an
assumption that timestamp cannot be smaller than 2,000,000,000 (second second
since epoch in nanos or year 2033 in millis), but that seems like a limiting
assumption. We could add option to disabled this check though but then they
could run into a situation when timestamp is small at a runtime and break their
application with this exception.
> we could proactively reject operations from old clients
Old clients still work with this attribute, users would have to update code
everywhere to use java.time.Instant so I don't really see how checking client
version would help here.
Another idea would be disallow altering table to set NANOSECOND_TIMESTAMPS
attribute. The table has to be created with nanos from scratch. I assume that
when the table created first time with this attribute, the users are starting
to write a new application from scratch on dev environment. This would
hopefully rule out the case of clients adding this attribute by accident to
existing table and corrupting their data.
> 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,
> 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)
