[
https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932000#comment-15932000
]
stack commented on HBASE-16417:
-------------------------------
Thanks for the nice writeup.
bq. . Basic improves the 50th percentile by 7% but the performance of 95th and
99th percentile degrade the performance by 15-30%.
Adding merge fixes the above 99th percentile degradation? You say it does at
the end of the paragraph.
I don't get why reading from multiple indices ups our latency, unless the
lookups are serial (i.e. why we need the merge).
bq. Note that in sync wal mode all policies have the same number of wal files
and the same volume of wal data. The number of wal file is smaller with async
wal for all policies (in zipfian and uniform key distribution). When you get
the answer to why thIS happens it might explain the number of wal files in
eager policy.
That is cool that async is faster for you (we were finding otherwise in our
tests... but this was without a regionserver context ... maybe we need to look
into this). Suggest you file an issue so we can answer the above [~eshcar] It
is an interesting question.
The charts show some nice, substantial dents in GC activity. Thats sweet.
So, enable BASIC+MERGE as default with EAGER for the case where a user knows
that they have a lot of duplicate data?
> 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,
> HBASE-16417-benchmarkresults-20170317.pdf
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
