hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7801) Allow a deferred sync option per Mutation.
Date Tue, 12 Feb 2013 05:41:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576399#comment-13576399
] 

Lars Hofhansl commented on HBASE-7801:
--------------------------------------

bq. This also to be default to defered = false
Absolutely. By default nothing will change.

bq. When the attribute is missing we can assume the value to be that set for the table?
Yep

bq. Here batch will be the mini batch.
Yes. Ideally we would only sync or defer those edits that need it, but if we sync or defer
a few more in the batch it is still correct behavior.

Not sure I completely follow your last paragraph. We need to control the sync and a periodic
backround sync is not good enough?
By setting defer sync you implicitly declare that you are OK with losing (some of) the data
in rare cases. If that is not acceptable you'd need sync (not defer) I think.

Maybe in 0.96 we can think about a way how group edits for different regions (on the same
server) and write them into a single WALEdit (similar to RowMutations, but for multiple regions).

                
> Allow a deferred sync option per Mutation.
> ------------------------------------------
>
>                 Key: HBASE-7801
>                 URL: https://issues.apache.org/jira/browse/HBASE-7801
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Lars Hofhansl
>             Fix For: 0.96.0, 0.94.6
>
>
> Won't have time for parent. But a deferred sync option on a per operation basis comes
up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a special mutation
attribute.
> For batch operation we'd take the safest sync option of any of the mutations. I.e. if
there is at least one that wants to be flushed we'd sync the batch, if there's none of those
but at least one that wants deferred flush we defer flush the batch, etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message