[
https://issues.apache.org/jira/browse/HBASE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849425#action_12849425
]
Todd Lipcon commented on HBASE-2353:
------------------------------------
Andrew, I agree with you in sentiment, but I also want to weigh in code
complexity and QA. Specific to this issue (trying to drag this runaway train
back!) I think it is very dangerous to have a configuration option that changes
the _order_ in which key operations occur. It makes it very tough to reason
about how different processes will affect the system, especially if this sort
of config option proliferates. And the matrix of configurations that we'll have
to test explodes in a really bad way.
> HBASE-2283 removed bulk sync optimization for multi-row puts
> ------------------------------------------------------------
>
> Key: HBASE-2353
> URL: https://issues.apache.org/jira/browse/HBASE-2353
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Fix For: 0.21.0
>
> Attachments: HBASE-2353-deferred.txt
>
>
> previously to HBASE-2283 we used to call flush/sync once per put(Put[]) call
> (ie: batch of commits). Now we do for every row.
> This makes bulk uploads slower if you are using WAL. Is there an acceptable
> solution to achieve both safety and performance by bulk-sync'ing puts? Or
> would this not work in face of atomic guarantees?
> discuss!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
