No. 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, > Sonal > Crux: Reporting for HBase <https://github.com/sonalgoyal/crux> > Nube Technologies <http://www.nubetech.co> > > <http://in.linkedin.com/in/sonalgoyal> > > > > > > On Mon, Jul 9, 2012 at 6:49 PM, Asaf Mesika <[email protected]> wrote: > >> Hi, >> >> We've been tinkering around ideas of implementing secondary index. >> One of the ideas is based on concatenating three meaningful fields into a >> long: int, short (2 bytes), short. This long will be used as timestamp when >> issuing a put to the secondary index table. >> This means an puts, timestamp wise, will not occur chronologically. since >> this is not a real timestamp. >> >> Will this create any issues? >> >> >> Thanks! >> >> Asaf >> >>
