[
https://issues.apache.org/jira/browse/HBASE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852187#action_12852187
]
Andrew Purtell commented on HBASE-2294:
---------------------------------------
bq. by default we do not allow stale reads, but in the future we could add a
flag on get() calls that explicitly allows it
If we accept a degraded mode of operation (HBASE-2183) while HDFS is
unavailable or a region is taking on IOEs (switch to read only cascades from
region to table), then there will be circumstances where the guarantees
normally made by the system will not apply. I would expect the initial strategy
to be something like:
- Stop accepting writes
- Serve data available in cache, set flag or field in response to indicate
degraded operation
- Serve data available in disk stores that can still be accessed, whichever are
not throwing IOEs.
This is relevant to this issue in the sense that committed data may temporarily
"disappear".
> 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
> Assignee: 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.
