You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Clint Morgan (JIRA)" <ji...@apache.org> on 2010/02/24 04:01:28 UTC
[jira] Created: (HBASE-2256) Delete row, followed quickly to put of
the same row will sometimes fail.
Delete row, followed quickly to put of the same row will sometimes fail.
------------------------------------------------------------------------
Key: HBASE-2256
URL: https://issues.apache.org/jira/browse/HBASE-2256
Project: Hadoop HBase
Issue Type: Bug
Affects Versions: 0.20.3
Reporter: Clint Morgan
Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2256) Delete row, followed quickly to put
of the same row will sometimes fail.
Posted by "Clint Morgan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837918#action_12837918 ]
Clint Morgan commented on HBASE-2256:
-------------------------------------
Yes, I'm sure that the millisecond nature of timestamps comes in to play here. However, I'm not setting any timestamps, and was under the impression that hbase would always reflect the state of the last operation done. Is this not a valid assumption?
A related question. If I do two puts (w/latest timestamp), am I guaranteed to see the last one? I'm sure many users operate under this assumption.
So, for a given row, I'm doing a delete of an entire row, then a put of two cells in different families. Then I do a get.
Most times I'll see all of the latest put. Sometimes I see nothing for that row. Sometimes I see just one family/cell from the previous put. It seems with 0.20.2 I would either get all the row, or none. However with 0.20.3 I will see all or just one family. Returning just one family seems even more wrong.
So suppose I wish to wipe existing cells of a row, then write some new cells. Is the only way to reliably do this to put a 1 ms pause between the delete and the put? This would hurt my throughput...
> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>
> Key: HBASE-2256
> URL: https://issues.apache.org/jira/browse/HBASE-2256
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Clint Morgan
> Attachments: hbase-2256.patch
>
>
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2256) Delete row, followed quickly to put
of the same row will sometimes fail.
Posted by "ryan rawson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838746#action_12838746 ]
ryan rawson commented on HBASE-2256:
------------------------------------
there is a millisecond resolution, and it might be difficult to get better without changing the storage format so we can get nanos in there.
but still, for most people, doing a put - delete - put all within 1 millisecond is a not common. maybe it might be possible to change something so we dont have to run up against this issue?
> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>
> Key: HBASE-2256
> URL: https://issues.apache.org/jira/browse/HBASE-2256
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Clint Morgan
> Attachments: hbase-2256.patch
>
>
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2256) Delete row, followed quickly to put
of the same row will sometimes fail.
Posted by "ryan rawson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837590#action_12837590 ]
ryan rawson commented on HBASE-2256:
------------------------------------
isnt this due to the millisecond timestamp nature of our puts and delete markers? If the next put has the same millisecond TS as an existing delete record you will be masked by the previous delete.
> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>
> Key: HBASE-2256
> URL: https://issues.apache.org/jira/browse/HBASE-2256
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Clint Morgan
> Attachments: hbase-2256.patch
>
>
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2256) Delete row, followed quickly to put
of the same row will sometimes fail.
Posted by "Clint Morgan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837947#action_12837947 ]
Clint Morgan commented on HBASE-2256:
-------------------------------------
I have only noticed this in unit tests and a non-distributed setup. However, this Delete,Put happens in ITHbase's IndexRegion which means that even in a distributed setup the client for the put/delete and the regionserver handling them could be in the same JVM.
For the put, put case, it seems to me this could be a real issue. Even in distributed setup sequential puts could happen in the same ms no? However, I did a similar test for Put after Put and it seems to always work. If it did not, I'm sure users would have complained loudly by now.
>From my point of view, it would be nice to have this behavior for Put after Delete as well.
I'm not saying I need finer granularity tham ms. Just that when I'm never explicitly messing with timestamps, I always see a "correct" view that reflects my last operation. I just skimmed over the bigtable paper, and could not find an explication about what they do in this case..
> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>
> Key: HBASE-2256
> URL: https://issues.apache.org/jira/browse/HBASE-2256
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Clint Morgan
> Attachments: hbase-2256.patch
>
>
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-2256) Delete row, followed quickly to put of
the same row will sometimes fail.
Posted by "Clint Morgan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Clint Morgan updated HBASE-2256:
--------------------------------
Attachment: hbase-2256.patch
> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>
> Key: HBASE-2256
> URL: https://issues.apache.org/jira/browse/HBASE-2256
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Clint Morgan
> Attachments: hbase-2256.patch
>
>
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2256) Delete row, followed quickly to put
of the same row will sometimes fail.
Posted by "Jean-Daniel Cryans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12837923#action_12837923 ]
Jean-Daniel Cryans commented on HBASE-2256:
-------------------------------------------
bq. Yes, I'm sure that the millisecond nature of timestamps comes in to play here. However, I'm not setting any timestamps, and was under the impression that hbase would always reflect the state of the last operation done. Is this not a valid assumption?
Do you see this delete problem even on a fully distributed setup? In my experience, they only happen in unit tests where all components are in the same JVM whereas when network is involved some milliseconds will separate two consecutive operations.
bq. A related question. If I do two puts (w/latest timestamp), am I guaranteed to see the last one? I'm sure many users operate under this assumption.
If they have the same timestamp, there's no guarantee.
bq. So, for a given row, I'm doing a delete of an entire row, then a put of two cells in different families. Then I do a get.
See my first comment, it's ok when not done in unit tests. Like the bigtable paper says, if you need a finer granularity than millisecond you may need to redefine the timestamps (using something like microseconds).
> Delete row, followed quickly to put of the same row will sometimes fail.
> ------------------------------------------------------------------------
>
> Key: HBASE-2256
> URL: https://issues.apache.org/jira/browse/HBASE-2256
> Project: Hadoop HBase
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Clint Morgan
> Attachments: hbase-2256.patch
>
>
> Doing a Delete of a whole row, followed immediately by a put to that row will sometimes miss a cell. Attached is a test to provoke the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.