If the 'int' parts of your rowkeys are close to each other, you may
On Monday, July 9, 2012, Asaf Mesika <[EMAIL PROTECTED]> wrote:
> My index is composed of several fields. Some goes to the RowKey, some to
the column name, and some - and hence the question - to timestamp.
> Those that goes to the timestamp are of types Integer, Short and short
which together form 8 bytes - the size of the Timestamp in hbase.
> So my question was if that's ok? I mean, it seems that the normal usage
for the timestamp is to have a timestamp (ms since epoch) and to have
values there which always increasing - meaning: you'll never see value 7
enters *before* value 3, for example.
> On Jul 9, 2012, at 18:54 PM, Sonal Goyal wrote:
>> Sorry I did not understand your question. Are you planning to use the
>> concatenated long as the rowkey to your secondary table?
>> Best Regards,
>> Crux: Reporting for HBase <https://github.com/sonalgoyal/crux>
>> Nube Technologies <http://www.nubetech.co>
>> On Mon, Jul 9, 2012 at 6:49 PM, Asaf Mesika <[EMAIL PROTECTED]>
>>> We've been tinkering around ideas of implementing secondary index.
>>> One of the ideas is based on concatenating three meaningful fields into
>>> long: int, short (2 bytes), short. This long will be used as timestamp
>>> issuing a put to the secondary index table.
>>> This means an puts, timestamp wise, will not occur chronologically.
>>> this is not a real timestamp.
>>> Will this create any issues?