[
https://issues.apache.org/jira/browse/HBASE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845605#action_12845605
]
stack commented on HBASE-2294:
------------------------------
Above looks good to me Ryan. Only thing I'd change would be the language. It
should be rewritten in spec-speak. For example, rather than "should be
atomic", in a spec., we'd say "are atomic" (and its a bug if it ain't so).
Regards scanners, we should be clearer that they'll never see partial updates
to a row (even if it is made from many families), or in other words, that they
respect row locks. Also if no timestamp is specified, scanners will return the
state of the row as of the time the scanner encounters the row. Otherwise, if
the scanner is opened with an explicit timestamp, they'll return the state of
the row as of the specified timestamp.
I think we need to probably also describe how a Scanner moves through a table
explaining what rows it will return.
We should probably talk up how deletes work too though I think it should be
plain given the above, we probably should just spell it out in a spec.
> 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.
