hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: Still Seeing Old Data After a Delete
Date Tue, 27 Mar 2012 18:19:04 GMT
Yes, this is quite confusing. Delete.deleteColumn should really be called deleteVersion or
I wonder whether we could make a change like this in the 0.96 "singularity" release.

-- Lars

 From: Shawn Quinn <squinn@moxiegroup.com>
To: user@hbase.apache.org; lars hofhansl <lhofhansl@yahoo.com> 
Sent: Tuesday, March 27, 2012 10:33 AM
Subject: Re: Still Seeing Old Data After a Delete

Hi Lars,

Thanks for the quick reply!  In this case we we're doing a column delete like so:

            Delete delete = new Delete(rowKey);
            delete.deleteColumn(Bytes.toBytes("thing"), Bytes.toBytes(value));

However, your response caused me to notice the "Delete.deleteColumns()" method in the JavaDoc
instead of simply "Delete.deleteColumn()".  Calling the "deleteColumns" instead of "deleteColumn"
fixes the problem we were seeing.  That wasn't immediately obvious to me after reading the
book, but after reading the JavaDoc I now understand the distinction between the two methods. 

I may be the only one who missed that at first, but in case others have a similar confusion
it might be worth a comment in the book that "deleteColumn()" is really only for deleting
a single version and "deleteColumns()" is for deleting all versions.  E.g. the second type
noted in the book currently is listed as "Delete column:  for all versions of a column". 
But, from the API perspective that's really the "deleteColumns()" method.  (Whereas, my incorrect
intuition when just looking at the API was that the "deleteColumns()" method would likely
be for deleting multiple different columns.)

Thanks again for the quick follow up,


On Tue, Mar 27, 2012 at 1:19 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

Hey Shawn,
>how exactly did you delete the column?
>There are three types of delete markers: family, column, version.
>Your observation would be consistent with having used a version delete marker, which just
marks are a specific version (the latest by default) for delete.
>Check out the HBase Reference Guide: http://hbase.apache.org/book.html#version.delete
>Also, if you don't mind the plug see a more detailed discussion here: http://hadoop-hbase.blogspot.com/2011/12/deletion-in-hbase.html
>-- Lars
>----- Original Message -----
>From: Shawn Quinn <squinn@moxiegroup.com>
>To: user@hbase.apache.org
>Sent: Tuesday, March 27, 2012 10:01 AM
>Subject: Still Seeing Old Data After a Delete
>In a couple of situations we were noticing some odd problems with old data
>appearing in the application, and I finally found a reproducible scenario.
>Here's what we're seeing in one basic case:
>1. Using a scan in hbase shell one of our column cells (both the column
>name and value are simple long's) looks like so:
>column=thing:\x00\x00\x00\x00\x00\x00\x00\x02, timestamp=1332795701976,
>2. If we then use a "Put" to update that cell to a new value it looks as
>we'd expect like so:
>column=thing:\x00\x00\x00\x00\x00\x00\x00\x02, timestamp=1332866682295,
>3. If we then use a "Delete" to remove that column, instead of the column
>no longer being included in the scan we instead see the following again:
>column=thing:\x00\x00\x00\x00\x00\x00\x00\x02, timestamp=1332795701976,
>So, for some reason, at least in this case, the tombstone/delete marker
>doesn't appear to be preventing new scans from no longer seeing the old
>Note that this is a small development cluster of HBase (version:
>hbase-0.90.4-cdh3u2) which contains one master and three region servers,
>and I have confirmed that the clocks are synchronized properly between the
>four machines.  Also note that we're using the Java client API to run the
>Put/Delete commands noted above.
>Any ideas on how old data could still appear in a Get/Scan like this, and
>if there are any workarounds we could try?  I saw HBASE-4536, but after
>reading that thread it didn't seem pertinent to this more basic scenario.
>Thanks in advance for any pointers!
>      -Shawn
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message