Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB