hbase-issues mailing list archives

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

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

Anoop Sam John commented on HBASE-7801:
---------------------------------------

bq.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.
Lars I dont need the defered sync in any of the mutation. So every mini batch operation will
do a wal write and then one sync at [STEP 7. Sync wal]
What my point was we have the LogSyncer thread running. It can come and do a sync before the
thread, doing the write, coming and doing the sync at step#7.  In our case we have to make
sure the sync is happening as one unit for the main region and index region. We do write WAL
entry for the index region in CP WAL write hooks.

bq.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).
I was also thinking in this way. This is already a backlog item I have added for myself here
which comes in our sec index further optimization points :)
Thanks Lars. I will see working with item.
                
> 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