[
https://issues.apache.org/jira/browse/HBASE-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849407#action_12849407
]
Jonathan Gray commented on HBASE-2353:
--------------------------------------
I agree with Andrew. We were always burdened in the Postgres world by having
horrid out-of-the-box performance, but awesome out-of-the-box durability.
Being able to adjust these things for performance vs durability guarantees is
awesome.
Whichever the default is, there must be ample documentation explaining the
various knobs and various trade-offs. People running HBase without diving into
those docs are far more likely to be testing for performance, not durability.
They will also likely not be in a production environment, or on clusters large
enough and be running for enough time that node failure is likely.
> 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.
