hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <enis....@gmail.com>
Subject Re: Timestamp resolution
Date Sat, 24 May 2014 00:56:32 GMT
Also relevant:

https://issues.apache.org/jira/browse/HBASE-8927
https://issues.apache.org/jira/browse/HBASE-6833


On Fri, May 23, 2014 at 5:54 PM, Enis Söztutar <enis.soz@gmail.com> wrote:

> +1 to micros. We should do it at the table level rather than CF level?
>
> How can we get the micros resolution efficiently in java?
>
> Enis
>
>
> On Fri, May 23, 2014 at 5:27 PM, lars hofhansl <larsh@apache.org> wrote:
>
>> We have discussed this in the past. It just came up again during an
>> internal discussion.
>> Currently we simply store a Java timestamp (millisec since epoch), i.e.
>> we have ms resolution.
>>
>> We do have 8 bytes for the TS, though. Not enough to store nanosecs (that
>> would only cover 2^63/10^9/3600/24/365.24 = 292.279 years), but enough for
>> microseconds (292279 years).
>> Should we just store he TS is microseconds? We could do that right now
>> (and just keep the ms resolution for now - i.e. the us part would always be
>> 0 for now).
>> Existing data must be in ms of course, so we'd grandfather that in, but
>> new tables could store by default in us.
>>
>> We'd need to make this configurable both the column family level and
>> client level, so clients could still opt to see data in ms.
>>
>> Comments? Too much to bite off?
>>
>> -- Lars
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message