[
https://issues.apache.org/jira/browse/HBASE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14999342#comment-14999342
]
Andrew Purtell edited comment on HBASE-14791 at 11/10/15 8:58 PM:
--
bq. Essentially, we'd need to implement a basic BufferedMutator and use it for
both OutputFormat types. The downside is that we would be duplicating some of
the buffering code in HTable.
I think this is fine given the trade-offs here. We don't want to make a
significant change in HTable semantics in 0.98. We do want to improve
performance of TableOutputFormat substantially for Deletes. A reasonable option
is some 0.98-specific buffering in TableOutputFormat. It could be more
palatable a change if the new behavior is configurable, defaulting to off
(backwards compatible FWIW)
was (Author: apurtell):
bq. Essentially, we'd need to implement a basic BufferedMutator and use it for
both OutputFormat types. The downside is that we would be duplicating some of
the buffering code in HTable.
I think this is fine given the trade-offs here. We don't want to make a
significant change in HTable semantics in 0.98. We do want to improve
performance of TableOutputFormat substantially for Deletes. A reasonable option
is some 0.98-specific buffering in TableOutputFormat. It would be more
palatable a change if the new behavior is configurable, defaulting to off
(backwards compatible FWIW)
> [0.98] CopyTable is extremely slow when moving delete markers
> -
>
> Key: HBASE-14791
> URL: https://issues.apache.org/jira/browse/HBASE-14791
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.16
>Reporter: Lars Hofhansl
>Assignee: Alex Araujo
>
> We found that some of our copy table job run for many hours, even when there
> isn't that much data to copy.
> [~vik.karma] did his magic and found that the issue is with copying delete
> markers (we use raw mode to also move deletes across).
> Looking at the code in 0.98 it's immediately obvious that deletes (unlike
> puts) are not batched and hence sent to the other side one by one, causing a
> network RTT for each delete marker.
> Looks like in trunk it's doing the right thing (using BufferedMutators for
> all mutations in TableOutputFormat). So likely only a 0.98 (and 1.0, 1.1,
> 1.2?) issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
