You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Vladimir Rodionov <vr...@carrieriq.com> on 2012/06/05 20:19:45 UTC
Some suggestions for future features
1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
where KeyValue static class members are accessed directly.
2.Compaction callback. Can be HTable as well. Something like this one:
public interface CompactionCallback<KeyValue>
{
public void preCompact(KeyValue kv, CompactionContext ctx)
}
Developer can :
a. Modify KeyValue before compaction
or
b. Make HBase to delete row entirely
3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
There are a lot of use case where these features would be very helpful. What do you think?
Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com
Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
Re: Some suggestions for future features
Posted by Andrew Purtell <ap...@apache.org>.
On Wed, Jun 6, 2012 at 10:08 AM, Anoop Sam John <an...@huawei.com> wrote:
> Mean while Andrew I have just seen that in trunk the interface InternalScanner is marked as private [@InterfaceAudience.Private]
> Through the CP it is exposed now right. And the above use case need customer to implement this also. What about marking this Public?
It is always going to be the case that CPs will require access to
internals. That doesn't mean the APIs they use should be marked
Public, an exception being the CP framework APIs themselves.
InternalScanner should remain Private IMHO, it's in the name. :-)
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)
RE: Some suggestions for future features
Posted by Anoop Sam John <an...@huawei.com>.
>This is possible now with the coprocessor RegionObserver API.
Agree with Andrew. We can make use of the RegionObserver#preCompact() hook here I think. This allows to return an InternalScanner implementation. May be we can wrap the actual InternalScanner object. This wrapper can do the modifications on the KVs. Mean while Andrew I have just seen that in trunk the interface InternalScanner is marked as private [@InterfaceAudience.Private]
Through the CP it is exposed now right. And the above use case need customer to implement this also. What about marking this Public? Correct me if my understanding is wrong pls...
Similar discussion is underway in HBASE-5974 regarding marking RegionScanner as Public.
-Anoop-
________________________________________
From: Andrew Purtell [apurtell@apache.org]
Sent: Wednesday, June 06, 2012 1:23 PM
To: dev@hbase.apache.org
Subject: Re: Some suggestions for future features
For this one...
On Tue, Jun 5, 2012 at 8:19 PM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
> 2.Compaction callback. Can be HTable as well. Something like this one:
>
> public interface CompactionCallback<KeyValue>
> {
> public void preCompact(KeyValue kv, CompactionContext ctx)
> }
>
> Developer can :
> a. Modify KeyValue before compaction
> or
> b. Make HBase to delete row entirely
This is possible now with the coprocessor RegionObserver API.
What is the motivation here for adding another API?
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)
Re: Some suggestions for future features
Posted by Andrew Purtell <ap...@apache.org>.
For this one...
On Tue, Jun 5, 2012 at 8:19 PM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
> 2.Compaction callback. Can be HTable as well. Something like this one:
>
> public interface CompactionCallback<KeyValue>
> {
> public void preCompact(KeyValue kv, CompactionContext ctx)
> }
>
> Developer can :
> a. Modify KeyValue before compaction
> or
> b. Make HBase to delete row entirely
This is possible now with the coprocessor RegionObserver API.
What is the motivation here for adding another API?
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)
RE: Some suggestions for future features
Posted by Vladimir Rodionov <vr...@carrieriq.com>.
CompactionCallback API needs to be part of a Coprocessor API of course
Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com
________________________________________
From: Vladimir Rodionov
Sent: Tuesday, June 05, 2012 11:19 AM
To: dev@hbase.apache.org
Subject: Some suggestions for future features
1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
where KeyValue static class members are accessed directly.
2.Compaction callback. Can be HTable as well. Something like this one:
public interface CompactionCallback<KeyValue>
{
public void preCompact(KeyValue kv, CompactionContext ctx)
}
Developer can :
a. Modify KeyValue before compaction
or
b. Make HBase to delete row entirely
3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
There are a lot of use case where these features would be very helpful. What do you think?
Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com
Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
RE: Some suggestions for future features
Posted by Vladimir Rodionov <vr...@carrieriq.com>.
This probably can not be done atomically w/o significant resource investments (time)
I am thinking about using special coprocessor for the vary same purpose. The only requirement I see right now
is custom compaction support, but Stack said that it is there already.
Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com
________________________________________
From: Ian Varley [ivarley@salesforce.com]
Sent: Tuesday, June 05, 2012 12:34 PM
To: dev@hbase.apache.org
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 [vrodionov@carrieriq.com]
> Sent: Wednesday, June 06, 2012 12:30 AM
> To: dev@hbase.apache.org
> 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: vrodionov@carrieriq.com
>
> ________________________________________
> From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
> Sent: Tuesday, June 05, 2012 11:43 AM
> To: dev@hbase.apache.org
> Subject: Re: Some suggestions for future features
>
> On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
> <vr...@carrieriq.com> wrote:
>>
>> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
>> where KeyValue static class members are accessed directly.
>
> Yes. Its our most fundamental class. Its tough to change since it
> there are a bunch of perf. fixes and a bunch of the upper tiers key
> off its format (and as you note, make direct calls against this
> class).
>
> That said, there is pressure building that KV should be an Interface
> only because others want to mess w/ its implementation (improve our
> cachability, compression).
>
> What would you like to do Vladimir? You want to change comparators?
>
>> 2.Compaction callback. Can be HTable as well. Something like this one:
>>
>> public interface CompactionCallback<KeyValue>
>> {
>> public void preCompact(KeyValue kv, CompactionContext ctx)
>> }
>>
>
> Is this not in Coproccessors now? See trunk. See Compactor.java down
> around #136 where the scanner used compacting is overrideable.
>
>
> St.Ack
>
> Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
RE: Some suggestions for future features
Posted by Anoop Sam John <an...@huawei.com>.
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 [lhofhansl@yahoo.com]
Sent: Wednesday, June 06, 2012 2:41 PM
To: dev@hbase.apache.org
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 <an...@huawei.com>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
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 [ivarley@salesforce.com]
Sent: Wednesday, June 06, 2012 1:04 AM
To: dev@hbase.apache.org
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 [vrodionov@carrieriq.com]
> Sent: Wednesday, June 06, 2012 12:30 AM
> To: dev@hbase.apache.org
> 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: vrodionov@carrieriq.com
>
> ________________________________________
> From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
> Sent: Tuesday, June 05, 2012 11:43 AM
> To: dev@hbase.apache.org
> Subject: Re: Some suggestions for future features
>
> On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
> <vr...@carrieriq.com> wrote:
>>
>> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
>> where KeyValue static class members are accessed directly.
>
> Yes. Its our most fundamental class. Its tough to change since it
> there are a bunch of perf. fixes and a bunch of the upper tiers key
> off its format (and as you note, make direct calls against this
> class).
>
> That said, there is pressure building that KV should be an Interface
> only because others want to mess w/ its implementation (improve our
> cachability, compression).
>
> What would you like to do Vladimir? You want to change comparators?
>
>> 2.Compaction callback. Can be HTable as well. Something like this one:
>>
>> public interface CompactionCallback<KeyValue>
>> {
>> public void preCompact(KeyValue kv, CompactionContext ctx)
>> }
>>
>
> Is this not in Coproccessors now? See trunk. See Compactor.java down
> around #136 where the scanner used compacting is overrideable.
>
>
> St.Ack
>
> Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
Re: Some suggestions for future features
Posted by lars hofhansl <lh...@yahoo.com>.
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 <an...@huawei.com>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
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 [ivarley@salesforce.com]
Sent: Wednesday, June 06, 2012 1:04 AM
To: dev@hbase.apache.org
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 [vrodionov@carrieriq.com]
> Sent: Wednesday, June 06, 2012 12:30 AM
> To: dev@hbase.apache.org
> 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: vrodionov@carrieriq.com
>
> ________________________________________
> From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
> Sent: Tuesday, June 05, 2012 11:43 AM
> To: dev@hbase.apache.org
> Subject: Re: Some suggestions for future features
>
> On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
> <vr...@carrieriq.com> wrote:
>>
>> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
>> where KeyValue static class members are accessed directly.
>
> Yes. Its our most fundamental class. Its tough to change since it
> there are a bunch of perf. fixes and a bunch of the upper tiers key
> off its format (and as you note, make direct calls against this
> class).
>
> That said, there is pressure building that KV should be an Interface
> only because others want to mess w/ its implementation (improve our
> cachability, compression).
>
> What would you like to do Vladimir? You want to change comparators?
>
>> 2.Compaction callback. Can be HTable as well. Something like this one:
>>
>> public interface CompactionCallback<KeyValue>
>> {
>> public void preCompact(KeyValue kv, CompactionContext ctx)
>> }
>>
>
> Is this not in Coproccessors now? See trunk. See Compactor.java down
> around #136 where the scanner used compacting is overrideable.
>
>
> St.Ack
>
> Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
RE: Some suggestions for future features
Posted by Anoop Sam John <an...@huawei.com>.
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 [ivarley@salesforce.com]
Sent: Wednesday, June 06, 2012 1:04 AM
To: dev@hbase.apache.org
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 [vrodionov@carrieriq.com]
> Sent: Wednesday, June 06, 2012 12:30 AM
> To: dev@hbase.apache.org
> 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: vrodionov@carrieriq.com
>
> ________________________________________
> From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
> Sent: Tuesday, June 05, 2012 11:43 AM
> To: dev@hbase.apache.org
> Subject: Re: Some suggestions for future features
>
> On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
> <vr...@carrieriq.com> wrote:
>>
>> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
>> where KeyValue static class members are accessed directly.
>
> Yes. Its our most fundamental class. Its tough to change since it
> there are a bunch of perf. fixes and a bunch of the upper tiers key
> off its format (and as you note, make direct calls against this
> class).
>
> That said, there is pressure building that KV should be an Interface
> only because others want to mess w/ its implementation (improve our
> cachability, compression).
>
> What would you like to do Vladimir? You want to change comparators?
>
>> 2.Compaction callback. Can be HTable as well. Something like this one:
>>
>> public interface CompactionCallback<KeyValue>
>> {
>> public void preCompact(KeyValue kv, CompactionContext ctx)
>> }
>>
>
> Is this not in Coproccessors now? See trunk. See Compactor.java down
> around #136 where the scanner used compacting is overrideable.
>
>
> St.Ack
>
> Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
Re: Some suggestions for future features
Posted by Ian Varley <iv...@salesforce.com>.
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 [vrodionov@carrieriq.com]
> Sent: Wednesday, June 06, 2012 12:30 AM
> To: dev@hbase.apache.org
> 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: vrodionov@carrieriq.com
>
> ________________________________________
> From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
> Sent: Tuesday, June 05, 2012 11:43 AM
> To: dev@hbase.apache.org
> Subject: Re: Some suggestions for future features
>
> On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
> <vr...@carrieriq.com> wrote:
>>
>> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
>> where KeyValue static class members are accessed directly.
>
> Yes. Its our most fundamental class. Its tough to change since it
> there are a bunch of perf. fixes and a bunch of the upper tiers key
> off its format (and as you note, make direct calls against this
> class).
>
> That said, there is pressure building that KV should be an Interface
> only because others want to mess w/ its implementation (improve our
> cachability, compression).
>
> What would you like to do Vladimir? You want to change comparators?
>
>> 2.Compaction callback. Can be HTable as well. Something like this one:
>>
>> public interface CompactionCallback<KeyValue>
>> {
>> public void preCompact(KeyValue kv, CompactionContext ctx)
>> }
>>
>
> Is this not in Coproccessors now? See trunk. See Compactor.java down
> around #136 where the scanner used compacting is overrideable.
>
>
> St.Ack
>
> Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
RE: Some suggestions for future features
Posted by Anoop Sam John <an...@huawei.com>.
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 [vrodionov@carrieriq.com]
Sent: Wednesday, June 06, 2012 12:30 AM
To: dev@hbase.apache.org
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: vrodionov@carrieriq.com
________________________________________
From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
Sent: Tuesday, June 05, 2012 11:43 AM
To: dev@hbase.apache.org
Subject: Re: Some suggestions for future features
On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
>
> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
> where KeyValue static class members are accessed directly.
Yes. Its our most fundamental class. Its tough to change since it
there are a bunch of perf. fixes and a bunch of the upper tiers key
off its format (and as you note, make direct calls against this
class).
That said, there is pressure building that KV should be an Interface
only because others want to mess w/ its implementation (improve our
cachability, compression).
What would you like to do Vladimir? You want to change comparators?
> 2.Compaction callback. Can be HTable as well. Something like this one:
>
> public interface CompactionCallback<KeyValue>
> {
> public void preCompact(KeyValue kv, CompactionContext ctx)
> }
>
Is this not in Coproccessors now? See trunk. See Compactor.java down
around #136 where the scanner used compacting is overrideable.
St.Ack
Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
RE: Some suggestions for future features
Posted by Vladimir Rodionov <vr...@carrieriq.com>.
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: vrodionov@carrieriq.com
________________________________________
From: saint.ack@gmail.com [saint.ack@gmail.com] On Behalf Of Stack [stack@duboce.net]
Sent: Tuesday, June 05, 2012 11:43 AM
To: dev@hbase.apache.org
Subject: Re: Some suggestions for future features
On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
>
> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
> where KeyValue static class members are accessed directly.
Yes. Its our most fundamental class. Its tough to change since it
there are a bunch of perf. fixes and a bunch of the upper tiers key
off its format (and as you note, make direct calls against this
class).
That said, there is pressure building that KV should be an Interface
only because others want to mess w/ its implementation (improve our
cachability, compression).
What would you like to do Vladimir? You want to change comparators?
> 2.Compaction callback. Can be HTable as well. Something like this one:
>
> public interface CompactionCallback<KeyValue>
> {
> public void preCompact(KeyValue kv, CompactionContext ctx)
> }
>
Is this not in Coproccessors now? See trunk. See Compactor.java down
around #136 where the scanner used compacting is overrideable.
St.Ack
Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
Re: Some suggestions for future features
Posted by Stack <st...@duboce.net>.
On Tue, Jun 5, 2012 at 11:19 AM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
>
> 1. Custom Key, KeyValue, Row Comparators (per HTable). I went through the 0.92 API and it seems that adding this feature is going to be hard task. There are a lot of places all over HBase source code
> where KeyValue static class members are accessed directly.
Yes. Its our most fundamental class. Its tough to change since it
there are a bunch of perf. fixes and a bunch of the upper tiers key
off its format (and as you note, make direct calls against this
class).
That said, there is pressure building that KV should be an Interface
only because others want to mess w/ its implementation (improve our
cachability, compression).
What would you like to do Vladimir? You want to change comparators?
> 2.Compaction callback. Can be HTable as well. Something like this one:
>
> public interface CompactionCallback<KeyValue>
> {
> public void preCompact(KeyValue kv, CompactionContext ctx)
> }
>
Is this not in Coproccessors now? See trunk. See Compactor.java down
around #136 where the scanner used compacting is overrideable.
St.Ack
RE: Some suggestions for future features
Posted by Anoop Sam John <an...@huawei.com>.
>We've started to implement a coprocessor to move the Scan and
Delete at RS level but, if the API above can delete also columns and not
entire rows then it will be welcomed :)
@Daniel
You are doing it using Endpoints?
@Dev
Can we provide a built in end point for this kind of bulk delete? We are now giving an Aggregation endpoint.
Handling this kind of scan and delete at server side itself will be giving performance boost.
I have done some basic implementation and tested for the performance advantage of this end point based delete over the normal way of scan to client and then delete. In the local mini cluster itself it is promising!
Also in this delete we need to use the bulk delete at region level. [See HBASE-6284]
-Anoop-
________________________________________
From: Daniel Iancu [daniel.iancu@1and1.ro]
Sent: Friday, June 08, 2012 10:17 PM
To: dev@hbase.apache.org
Cc: Andrew Purtell
Subject: Re: Some suggestions for future features
>> 3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
> This is interesting.
>
> Worth considering a Delete API that takes a Scan (or equivalent*) as argument?
>
> * - Possibly pulling up the start row, stop row, filter chain fields
> of Scan into a more generic object that can be passed to such an API
> and extended by Scan, if the use of Scan in an API like Delete leads
> in consensus opinion to a mixed metaphor.
We have a use case where we need to delete columns but we don't know
their rows. We run a Scan on a range of rows and custom-filter the rows
containg the columns to be deleted. Then we delete all the columns from
the Scan result. This is a 2 step operation and it implies networks
traffic. We've started to implement a coprocessor to move the Scan and
Delete at RS level but, if the API above can delete also columns and not
entire rows then it will be welcomed :)
Re: Some suggestions for future features
Posted by Daniel Iancu <da...@1and1.ro>.
>> 3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
> This is interesting.
>
> Worth considering a Delete API that takes a Scan (or equivalent*) as argument?
>
> * - Possibly pulling up the start row, stop row, filter chain fields
> of Scan into a more generic object that can be passed to such an API
> and extended by Scan, if the use of Scan in an API like Delete leads
> in consensus opinion to a mixed metaphor.
We have a use case where we need to delete columns but we don't know
their rows. We run a Scan on a range of rows and custom-filter the rows
containg the columns to be deleted. Then we delete all the columns from
the Scan result. This is a 2 step operation and it implies networks
traffic. We've started to implement a coprocessor to move the Scan and
Delete at RS level but, if the API above can delete also columns and not
entire rows then it will be welcomed :)
RE: Some suggestions for future features
Posted by Vladimir Rodionov <vr...@carrieriq.com>.
Scan implies scanning table and this is what I would like to avoid. I consider "bulk" delete as a hint (internal filter)
for HBase (RegionServer) execution of which can be deferred until actual region compaction kicks off.
Why does some one need this for? CF TTL is not enough in some cases and there is need to have more flexible API to perform
HBase housekeeping.
Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com
________________________________________
From: Andrew Purtell [apurtell@apache.org]
Sent: Wednesday, June 06, 2012 12:59 AM
To: dev@hbase.apache.org
Subject: Re: Some suggestions for future features
For this one...
On Tue, Jun 5, 2012 at 8:19 PM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
> 3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
This is interesting.
Worth considering a Delete API that takes a Scan (or equivalent*) as argument?
* - Possibly pulling up the start row, stop row, filter chain fields
of Scan into a more generic object that can be passed to such an API
and extended by Scan, if the use of Scan in an API like Delete leads
in consensus opinion to a mixed metaphor.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)
Confidentiality Notice: The information contained in this message, including any attachments hereto, may be confidential and is intended to be read only by the individual or entity to whom this message is addressed. If the reader of this message is not the intended recipient or an agent or designee of the intended recipient, please note that any review, use, disclosure or distribution of this message or its attachments, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com and delete or destroy any copy of this message and its attachments.
Re: Some suggestions for future features
Posted by Andrew Purtell <ap...@apache.org>.
For this one...
On Tue, Jun 5, 2012 at 8:19 PM, Vladimir Rodionov
<vr...@carrieriq.com> wrote:
> 3. Row prefix delete operation - Delete all rows which starts with a 'prefix'
This is interesting.
Worth considering a Delete API that takes a Scan (or equivalent*) as argument?
* - Possibly pulling up the start row, stop row, filter chain fields
of Scan into a more generic object that can be passed to such an API
and extended by Scan, if the use of Scan in an API like Delete leads
in consensus opinion to a mixed metaphor.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)