[
https://issues.apache.org/jira/browse/HBASE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845704#action_12845704
]
stack commented on HBASE-2294:
------------------------------
Thanks for putting together first cut Todd. Should we put it somewhere we can
all hack on it? Up on hbase wiki or over in public google doc?
+ Minor: In current API its called, checkAndPut rather than compareAndSave:
http://su.pr/2tPOlr
+ "XXX: will they return failure or success or some mixed response here?"
Failure with a list of what updates succeeded+failed (As per Aaron's JDBC
illustration).
+ "...at least as new as the beginning of the scan" could confuse, or rather,
to avoid confusion we need to explain all the ways in which the scanner works.
Whats being described is the case where no timestamp is specified on opening of
a scan. In this case we want to return the latest version of the row as of the
time the scanner happens upon it (the row). Even so, there is no reason why
the table row data may not be older than the scan opening. In this case we'd
return data older than scanner opening (Are you saying this Todd when you say
"at least as new.."?). Also, you can specify the timestamp range when you
open a scanner and in this case, it'll return cells that lie within the bounds
of the timestamp range irrepective of the time at which the scanner was opened.
+ On 'XXX: Ryan has mentioned the model of "scans will always get the most
up-to-date version of a row when beginning a new row". Do we want to guarantee
this or just leave it at "some version of the row at least as new as what
existed at scan start"?', I'm fine with either. The latter seems an easier
guarantee.
+ Is this a slip on your part Todd -> "...not durably on disk." Maybe we
should adjust your durable definition to suit what we can offer, or, maybe you
intend that we adjust the filesystem to match your durability definition?
+ +1 on adding the Henry amendment
+ On the 'time travel' requirement in the face of failure, how about we take it
on (with your note that it hard to do) so if 'time travel', its a bug.
> Enumerate ACID properties of HBase in a well defined spec
> ---------------------------------------------------------
>
> Key: HBASE-2294
> URL: https://issues.apache.org/jira/browse/HBASE-2294
> Project: Hadoop HBase
> Issue Type: Task
> Components: documentation
> Reporter: Todd Lipcon
> Priority: Blocker
> Fix For: 0.20.4, 0.21.0
>
>
> It's not written down anywhere what the guarantees are for each operation in
> HBase with regard to the various ACID properties. I think the developers know
> the answers to these questions, but we need a clear spec for people building
> systems on top of HBase. Here are a few sample questions we should endeavor
> to answer:
> - For a multicell put within a CF, is the update made durable atomically?
> - For a put across CFs, is the update made durable atomically?
> - Can a read see a row that hasn't been sync()ed to the HLog?
> - What isolation do scanners have? Somewhere between snapshot isolation and
> no isolation?
> - After a client receives a "success" for a write operation, is that
> operation guaranteed to be visible to all other clients?
> etc
> I see this JIRA as having several points of discussion:
> - Evaluation of what the current state of affairs is
> - Evaluate whether we currently provide any guarantees that aren't useful to
> users of the system (perhaps we can drop in exchange for performance)
> - Evaluate whether we are missing any guarantees that would be useful to
> users of the system
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
