You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Ryan Rawson <ry...@gmail.com> on 2011/01/08 01:23:50 UTC
Getting rid of "delete forward" in HBase 0.92+, please weigh in
Hi all,
We are thinking of getting rid of the "delete forward" misfeature in
HBase. The one way we'd implement it would permanently remove this
"feature", and prevent it from being put back in ever.
What is a delete forward you ask? This is where you do a delete, but
because deletes are really just inserting 'tombstones', it applies to
future Puts. This can be immensely frustrating because puts appear to
do nothing. These rogue deletes get pruned out when the table is major
compacted, so it isn't forever.
Because of the transient nature of these delete forwards, we suspect,
but do not know, if anyone is depending on this behaviour. If you use
this behaviour, please chime in so we can get a sense of what people
need!
Thanks!
-ryan
Re: Getting rid of "delete forward" in HBase 0.92+, please weigh in
Posted by Ryan Rawson <ry...@gmail.com>.
Hi,
Right now deletes work by inserting a special delete marker, aka
"tombstone" complete with timestamp. The issue happens when you create
a delete with a timestamp in the future, it masks deletes that have
not happened yet. This is what I mean by "delete forward" - you are
deleting data that hasn't been inserted yet! From those used to
systems like MySQL, this is very confusing, hence this proposal.
-ryan
On Sat, Jan 8, 2011 at 1:29 AM, Henning Blohm <he...@zfabrik.de> wrote:
> +1 from here as well
>
> Please let delete work as if it was just a special marker value of a
> column (i.e. with a time stamp and all).
>
> On Fri, 2011-01-07 at 19:24 -0800, M. C. Srivas wrote:
>
>> +1
>>
>> Just a clarification : by delete-forward, do you mean that a delete of a
>> non-existent key causes a future insert of the key to get deleted?
>>
>>
>> On Fri, Jan 7, 2011 at 4:23 PM, Ryan Rawson <ry...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > We are thinking of getting rid of the "delete forward" misfeature in
>> > HBase. The one way we'd implement it would permanently remove this
>> > "feature", and prevent it from being put back in ever.
>> >
>> > What is a delete forward you ask? This is where you do a delete, but
>> > because deletes are really just inserting 'tombstones', it applies to
>> > future Puts. This can be immensely frustrating because puts appear to
>> > do nothing. These rogue deletes get pruned out when the table is major
>> > compacted, so it isn't forever.
>> >
>> > Because of the transient nature of these delete forwards, we suspect,
>> > but do not know, if anyone is depending on this behaviour. If you use
>> > this behaviour, please chime in so we can get a sense of what people
>> > need!
>> >
>> > Thanks!
>> > -ryan
>> >
>
Re: Getting rid of "delete forward" in HBase 0.92+, please weigh in
Posted by Henning Blohm <he...@zfabrik.de>.
+1 from here as well
Please let delete work as if it was just a special marker value of a
column (i.e. with a time stamp and all).
On Fri, 2011-01-07 at 19:24 -0800, M. C. Srivas wrote:
> +1
>
> Just a clarification : by delete-forward, do you mean that a delete of a
> non-existent key causes a future insert of the key to get deleted?
>
>
> On Fri, Jan 7, 2011 at 4:23 PM, Ryan Rawson <ry...@gmail.com> wrote:
>
> > Hi all,
> >
> > We are thinking of getting rid of the "delete forward" misfeature in
> > HBase. The one way we'd implement it would permanently remove this
> > "feature", and prevent it from being put back in ever.
> >
> > What is a delete forward you ask? This is where you do a delete, but
> > because deletes are really just inserting 'tombstones', it applies to
> > future Puts. This can be immensely frustrating because puts appear to
> > do nothing. These rogue deletes get pruned out when the table is major
> > compacted, so it isn't forever.
> >
> > Because of the transient nature of these delete forwards, we suspect,
> > but do not know, if anyone is depending on this behaviour. If you use
> > this behaviour, please chime in so we can get a sense of what people
> > need!
> >
> > Thanks!
> > -ryan
> >
Re: Getting rid of "delete forward" in HBase 0.92+, please weigh in
Posted by Ryan Rawson <ry...@gmail.com>.
Yes that's it exactly!
On Jan 7, 2011 7:24 PM, "M. C. Srivas" <mc...@gmail.com> wrote:
> +1
>
> Just a clarification : by delete-forward, do you mean that a delete of a
> non-existent key causes a future insert of the key to get deleted?
>
>
> On Fri, Jan 7, 2011 at 4:23 PM, Ryan Rawson <ry...@gmail.com> wrote:
>
>> Hi all,
>>
>> We are thinking of getting rid of the "delete forward" misfeature in
>> HBase. The one way we'd implement it would permanently remove this
>> "feature", and prevent it from being put back in ever.
>>
>> What is a delete forward you ask? This is where you do a delete, but
>> because deletes are really just inserting 'tombstones', it applies to
>> future Puts. This can be immensely frustrating because puts appear to
>> do nothing. These rogue deletes get pruned out when the table is major
>> compacted, so it isn't forever.
>>
>> Because of the transient nature of these delete forwards, we suspect,
>> but do not know, if anyone is depending on this behaviour. If you use
>> this behaviour, please chime in so we can get a sense of what people
>> need!
>>
>> Thanks!
>> -ryan
>>
Re: Getting rid of "delete forward" in HBase 0.92+, please weigh in
Posted by "M. C. Srivas" <mc...@gmail.com>.
+1
Just a clarification : by delete-forward, do you mean that a delete of a
non-existent key causes a future insert of the key to get deleted?
On Fri, Jan 7, 2011 at 4:23 PM, Ryan Rawson <ry...@gmail.com> wrote:
> Hi all,
>
> We are thinking of getting rid of the "delete forward" misfeature in
> HBase. The one way we'd implement it would permanently remove this
> "feature", and prevent it from being put back in ever.
>
> What is a delete forward you ask? This is where you do a delete, but
> because deletes are really just inserting 'tombstones', it applies to
> future Puts. This can be immensely frustrating because puts appear to
> do nothing. These rogue deletes get pruned out when the table is major
> compacted, so it isn't forever.
>
> Because of the transient nature of these delete forwards, we suspect,
> but do not know, if anyone is depending on this behaviour. If you use
> this behaviour, please chime in so we can get a sense of what people
> need!
>
> Thanks!
> -ryan
>