hbase-issues mailing list archives

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

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

Edward Bortnikov commented on HBASE-17765:
------------------------------------------

Merge means that only the index data is restructured. We create a larger segment with one
index - but no data is copied. Also, we avoid using the SQM scan (more expensive), so duplicate
data versions are not eliminated. Bottom line - (1) the overhead and the space savings are
both between BASIC and EAGER, and (2) the tail read latency problem is solved. 

We'll be publishing the perf results shortly. Following that, let's collectively decide whether
MERGE should be a level between BASIC and EAGER, or maybe just become the new BASIC, for simplicity.


Thanks. 

> 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
(v6.3.15#6346)

Mime
View raw message