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

Switch to Threaded View
HBase >> mail # dev >> Some suggestions for future features


Copy link to this message
-
RE: Some suggestions for future features

Thanks a lot Lars for mentioning this and sharing your experience.   Will try to do some experiment with this with alternates. Haven't done any deep analysis or work on this yet.

-Anoop-
________________________________________
From: lars hofhansl [[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2012 2:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Some suggestions for future features

Careful when designing new delete markers (see my failed attempt in HBASE-5268).
For example: In order to perform a Get operation we need to know whether the CF/column/version is deleted or now.
So we always need to seek to the beginning of the row to see if there is a family delete marker.

Having a row-prefix marker leaves us with no defined spot to seek to and check for the delete marker and hence we'd need to scan everything.
(If you do not mind the plug I also describe this in more detail here: http://hadoop-hbase.blogspot.de/2012/01/scanning-in-hbase.html)

-- Lars
----- Original Message -----
From: Anoop Sam John <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, June 5, 2012 8:42 PM
Subject: RE: Some suggestions for future features

Hi
>Are you guys thinking this would be a "helper" class that just iterates over rows and marks them as deleted? Or any attempt to make it a more fundamental atomic delete operation that can run for rows co-located on a single region server?

Not the 1st one in my mind.. May be that will have lot of time overhead. Thinking abt can be there a special kind of Delete marker itself? At one region level it will be 100% atomic.. Across regions delete how to handle in the best way need to explore more...    Delete & read consistency might not be that important in our case. Still need to look into that area as well....  I will try to do some experiment, then only things will come more clear  :)
-Anoop-
________________________________________
From: Ian Varley [[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2012 1:04 AM
To: [EMAIL PROTECTED]
Subject: Re: Some suggestions for future features

Are you guys thinking this would be a "helper" class that just iterates over rows and marks them as deleted? Or any attempt to make it a more fundamental atomic delete operation that can run for rows co-located on a single region server? If the latter, my understanding of the prevailing opinion (of Todd, etc) is that we're wary of exposing the region concept explicitly in the API at all, because it's an implementation detail today.

Ian

On Jun 5, 2012, at 2:15 PM, Anoop Sam John wrote:

> Hi,
>
>> 3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
>
> Sometime back I was thinking about this. One usage came for us.[Which was low prioritized later ] I will try to work on this soon.
>
> -Anoop-
>
> ________________________________________
> From: Vladimir Rodionov [[EMAIL PROTECTED]]
> Sent: Wednesday, June 06, 2012 12:30 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Some suggestions for future features
>
> My bad, getting through all HBase API is not easy task. I will look at Coprocessor. more closely
>
> Custom Key comparator allows to perform some useful tricks such as:
>
> keeping rows in a chronological order (temporal locality) and allowing to access them by some rowid at the same time.
>
> id1:day1
> id2:day1
> id3:day2
> id4:day2
> id5:day2
>
> etc
> We preserve temporal locality for rows and access to the rows by ID at the same time
>
> Although, HBase does not support Get by row prefix API call we can use Scanner for that purpose.
>
>
> Best regards,
> Vladimir Rodionov
> Principal Platform Engineer
> Carrier IQ, www.carrieriq.com
> e-mail: [EMAIL PROTECTED]
>
> ________________________________________
> From: [EMAIL PROTECTED] [[EMAIL PROTECTED]] On Behalf Of Stack [[EMAIL PROTECTED]]
> Sent: Tuesday, June 05, 2012 11:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Some suggestions for future features
>
> On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov