Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase, mail # user - Composing your own timestamp


+
Asaf Mesika 2012-07-09, 13:19
+
Sonal Goyal 2012-07-09, 15:54
+
Asaf Mesika 2012-07-09, 17:08
+
Mohammad Tariq 2012-07-09, 22:08
Copy link to this message
-
Re: Composing your own timestamp
Asaf Mesika 2012-07-10, 03:31
The int, short, short part goes to the time stamp.

Thanks!

Sent from my iPad

On 10 ביול 2012, at 01:08, Mohammad Tariq <[EMAIL PROTECTED]> wrote:

> Hello Asaf,
>    If the 'int' parts of your rowkeys are close to each other, you may
> face hotspotting.
>
> Best
> -Tariq
>
> On Monday, July 9, 2012, Asaf Mesika <[EMAIL PROTECTED]> wrote:
>> 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
>>>>
>>>>
>>
>>
>
> --
> Regards,
>    Mohammad Tariq
+
Mohammad Tariq 2012-07-10, 08:02