hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anastasia Braginsky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17765) Reviving the merge possibility in the CompactingMemStore
Date Mon, 13 Mar 2017 09:20:04 GMT

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

Anastasia Braginsky commented on HBASE-17765:

[~anoop.hbase], in addition to what [~ebortnik] had answered you, your math is correct. 16
should be max and 30 stands there for safety. According to our recent experiments, we are
not sure the default way should be no merge. But let discuss it when we publish the results.
Currently the #segments in pipeline is configurable and can be any number. Pay attention that
this patch also fixes the bug according to which the region server wasn't updated with the
new sizes when the merge did happened.

> Reviving the merge possibility in the CompactingMemStore
> --------------------------------------------------------
>                 Key: HBASE-17765
>                 URL: https://issues.apache.org/jira/browse/HBASE-17765
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anastasia Braginsky
>            Assignee: Anastasia Braginsky
>             Fix For: 2.0.0
>         Attachments: HBASE-17765-V01.patch
> According to the new performance results presented in the HBASE-16417 we see that the
read latency of the 90th percentile of the BASIC policy is too big due to the need to traverse
through too many segments in the pipeline. In this JIRA we correct the bug in the merge sizing
calculations and allow pipeline size threshold to be a configurable parameter.

This message was sent by Atlassian JIRA

View raw message