hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12988) [Replication]Parallel apply edits on row-level
Date Tue, 30 Jun 2015 22:30:06 GMT

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

Andrew Purtell commented on HBASE-12988:

bq. The reason is that we'd have to regroup the edits with the writetime and sequencenumber
under which they originated. Since each Entry (WALKey, WALEdit pair) has a unique sequencenumber
we cannot pull the edits apart...

Yes, but:

bq. The WALKey (formerly HLogKey) also has logSeqNum and writeTime. Right now the sink only
uses the writeTime to update ageOfLastAppliedOp. If ever we want to use them - for ordering
or other guarantees - we cannot disentangle them from the WALEdits; i.e. we cannot regroup
Cell between WALEdits.

So we are not using the WALKey sequence number. Any pressing reason why we should? If not
we can deprecate and remove it. Likewise, we can document that writeTime is informational
and does not provide a guarantee of ordering. 

> [Replication]Parallel apply edits on row-level
> ----------------------------------------------
>                 Key: HBASE-12988
>                 URL: https://issues.apache.org/jira/browse/HBASE-12988
>             Project: HBase
>          Issue Type: Improvement
>          Components: Replication
>            Reporter: hongyu bi
>            Assignee: Lars Hofhansl
>         Attachments: 12988-v2.txt, 12988-v3.txt, 12988.txt, HBASE-12988-0.98.patch, ParallelReplication-v2.txt
> we can apply  edits to slave cluster in parallel on table-level to speed up replication
> update : per conversation blow , it's better to apply edits on row-level in parallel

This message was sent by Atlassian JIRA

View raw message