n your logical model you should manage the time dimension yourself.
Otherwise if you identities (i.e. row) with many versions, the builtin
TS might be better.
-- Lars
__**__
From: Henning Blohm
To: user
Sent: Saturday, August 10, 2013 6:26 AM
Subject: Using HBase time
o skip a lot of other versions. In the worst case the
>>> latest version of all KeyVales are on separate (HFile) blocks.
>>>
>>> The question of whether to use the builtin timestamps or model the time
>>> as part of the row keys (or even a time-column), is an
want a new row for each TS in
your logical model you should manage the time dimension yourself.
Otherwise if you identities (i.e. row) with many versions, the builtin TS might
be better.
-- Lars
________
From: Henning Blohm
To: user
Sent: Saturday, August 10, 2013 6:26 AM
S
entities (i.e. row) with many versions, the builtin TS
> might be better.
>
> -- Lars
>
>
> From: Henning Blohm
> To: user
> Sent: Saturday, August 10, 2013 6:26 AM
> Subject: Using HBase timestamps as natural versioning
>
>
&g
(i.e. row) with many versions, the builtin TS might
be better.
-- Lars
From: Henning Blohm
To: user
Sent: Saturday, August 10, 2013 6:26 AM
Subject: Using HBase timestamps as natural versioning
Hi,
we are managing some naturally time versioned data in HBase
Sent: Saturday, August 10, 2013 6:26 AM
Subject: Using HBase timestamps as natural versioning
Hi,
we are managing some naturally time versioned data in HBase. That is,
there are change events that have a specific time set and when such
event is handled, data in HBase, pertaining to the exact same
Hi,
we are managing some naturally time versioned data in HBase. That is,
there are change events that have a specific time set and when such
event is handled, data in HBase, pertaining to the exact same point in
time, is updated.
So far we are using HBase time stamps to model the time dimen
