[
https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15690099#comment-15690099
]
Anastasia Braginsky commented on HBASE-17081:
---------------------------------------------
The new patch is also on the RB. And I am copy-pasting one of my RB answers
here to make it more clear:
So here is how index-compaction now works:
1. THRESHOLD_PIPELINE_SEGMENTS is now set to 10
2. Till we reach this number of segment in the pipeline we will keep
flattening only and if there is snapshot request we will flush everything
3. There is a big chance we never reach THRESHOLD_PIPELINE_SEGMENTS
segments in the pipeline
4. Actually once the first segment is flattened, we will always flush
everything upon snapshot request (pay attention that none reverse the boolean
once it is set)
Regarding what to do the same in data-compaction case, Eshcar is currently
running the benchmarks with all possibilities and we can decide what is better
to do based on her experiments.
> Flush the entire CompactingMemStore content to disk
> ---------------------------------------------------
>
> Key: HBASE-17081
> URL: https://issues.apache.org/jira/browse/HBASE-17081
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Anastasia Braginsky
> Attachments: HBASE-17081-V01.patch, HBASE-17081-V02.patch,
> Pipelinememstore_fortrunk_3.patch
>
>
> Part of CompactingMemStore's memory is held by an active segment, and another
> part is divided between immutable segments in the compacting pipeline. Upon
> flush-to-disk request we want to flush all of it to disk, in contrast to
> flushing only tail of the compacting pipeline.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
