tag:blogger.com,1999:blog-7235509382075756737.post3638263010588582068..comments2024-03-29T00:30:50.881-07:00Comments on HBase: Secondary Indexes (Part II)Lars Hofhanslhttp://www.blogger.com/profile/17852987569207015300noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-7235509382075756737.post-47805311690691150102012-10-17T02:32:46.761-07:002012-10-17T02:32:46.761-07:00I think I didn't explain my concern properly. ...I think I didn't explain my concern properly. Suppose there was a step 1b in my scenario, where the client does a read and receives the updated value Y. Afterwards it would receive the old value X, which doesn't make sense since it should receive the updated value again or nothing at all.<br /><br />But doing bulk scans as you suggest would solve it anyway. Thanks for the insight!Anonymoushttps://www.blogger.com/profile/09934635957829870339noreply@blogger.comtag:blogger.com,1999:blog-7235509382075756737.post-52755537165443832282012-10-16T10:19:42.631-07:002012-10-16T10:19:42.631-07:00Thanks Daniel. I am not claiming to have all the a...Thanks Daniel. I am not claiming to have all the answers :)<br />It's good to discuss all the corner cases.<br /><br />The scenario you describe seems OK, though. The value (X) existed when the scan started, so it seems OK returning that. HBase never had scan consistency (or maybe I misunderstand?)<br /><br />Also if you do bulk scans, you'd scan all values along the index first, and then go back for the actual rows. In that case both X and Y would have been removed from the main table.Lars Hofhanslhttps://www.blogger.com/profile/17852987569207015300noreply@blogger.comtag:blogger.com,1999:blog-7235509382075756737.post-89062570744892402332012-10-15T04:12:27.911-07:002012-10-15T04:12:27.911-07:00Thanks a lot for the followup, the explanation mak...Thanks a lot for the followup, the explanation makes it much easier to understand the revised approach. <br /><br />I agree the solutions you propose solve the problem of ignoring an entry due to an update, but I think the complimentary problem still exists, which is returning both values. This could be easily solved at client-side making sure you only keep the most up-to-date entry for each row.<br /><br />There are some corner cases, though (if I understood your revisions correctly). Let me put an example:<br /><br /> 1. row R has an indexed column with value X, and a client updates it to value Y<br /> 2. a long time later, the same client starts reading the index<br /> 3. it just passed index entry X<br /> 4. since there is an old version on the main row with value X, we return it for the time being (techniques #1 and #2)<br /> 5. another client deletes row R, and all index entries including X and Y<br /> 6. the first client continues reading the index until the end, skipping Y which was deleted<br /><br />The problem here is that the client received a really old value X instead of the updated Y or nothing at all (if the delete was "ordered" before the scan)<br /><br />Do you think this is a problem? Otherwise, this implementation could always return arbitrarily old values, violating again the contract of the scan operation.<br /><br />I'm sorry for being tedious but I'm really interested on this topic. I think this could help HBase as a whole if it was clear which guarantees could be provided by default and which guarantees need an external transactional implementation.<br /><br />Regards<br />Anonymoushttps://www.blogger.com/profile/09934635957829870339noreply@blogger.com