[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904483#comment-15904483
]
Anoop Sam John commented on HBASE-16417:
----------------------------------------
bq.how you think the numbers would change if 'default' 1k values were used?
Would we see the same benefit do you think?
I guess the improvement will be on decreasing side as the value size increases.
When val size is low like 100 bytes, there will be more #cells added to CLSM
before a flush to disk and more overhead in heap size. The in memory flush
(BASIC) reduces this overhead greatly and also avoids the situation of adding
more and more cells to an already large CSLM. But when val size is more, we
might be dealing with much lesser #cells. This is what my thinking is.
bq.The current default active segment size cap for in-memory flush is 1/4 the
memstore size cap for disk flush. Which means that the expected number of
segments in the pipeline is 4/2=2.
Why 4/2? Sorry am not getting.. As 25% is the in memory flush cap, ideally 4
segments can be there (It is basic type and no merge).. But we have a blocking
factor of 4 by default for the memstore flush size. Means we will allow max
memstore size of 128 MB * 4 before a forceful flush to disk. So 4 * 4 = 16
can be the max #segments? My math is wrong some where? I was not getting that
/2 thing.
> In-Memory MemStore Policy for Flattening and Compactions
> --------------------------------------------------------
>
> Key: HBASE-16417
> URL: https://issues.apache.org/jira/browse/HBASE-16417
> Project: HBase
> Issue Type: Sub-task
> Reporter: Anastasia Braginsky
> Assignee: Eshcar Hillel
> Fix For: 2.0.0
>
> Attachments: HBASE-16417-benchmarkresults-20161101.pdf,
> HBASE-16417-benchmarkresults-20161110.pdf,
> HBASE-16417-benchmarkresults-20161123.pdf,
> HBASE-16417-benchmarkresults-20161205.pdf,
> HBASE-16417-benchmarkresults-20170309.pdf
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
