hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14920) Compacting Memstore
Date Thu, 05 May 2016 16:58:12 GMT

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

stack commented on HBASE-14920:

bq. If we only consider the second case and flush the entire content to disk with every flush
request, we significantly weaken the feature strength. 

I'd think this would happen extremely rarely and when it does, I'd think it an emergency or
a dev testing.

bq. Alternatively, we can have this feature well documented, so that user understand that
if they wish to clear the memory they may need to invoke flush several times.

We could do this too, yes.

bq. So in this case as well a user request is not satisfied, and the user should be able to
handle this.

Nod. Sounds like documenting that it make take a few attempts to clear memory is the way to

If a user is persistent, will all memory be flushed from pipeline (each user click moves a
segment? So if N segments, it will take N clicks to clear all memory?)

That'd be fine I'd say.

> Compacting Memstore
> -------------------
>                 Key: HBASE-14920
>                 URL: https://issues.apache.org/jira/browse/HBASE-14920
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Eshcar Hillel
>            Assignee: Eshcar Hillel
>         Attachments: HBASE-14920-V01.patch, HBASE-14920-V02.patch, HBASE-14920-V03.patch,
HBASE-14920-V04.patch, HBASE-14920-V05.patch, HBASE-14920-V06.patch, HBASE-14920-V07.patch,
> Implementation of a new compacting memstore with non-optimized immutable segment representation

This message was sent by Atlassian JIRA

View raw message