[
https://issues.apache.org/jira/browse/HBASE-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275404#comment-15275404
]
stack commented on HBASE-14920:
-------------------------------
Here is an attempt at addressing [~anoop.hbase] concern that in-memory flushes
could have us flushing small files; correct me if I have it wrong [~eshcar]
As I understand it, we flush a single Segment at a time to disk. In current
patch where there is no pipeline -- an in-memory flush makes a Segment which is
the Snapshot -- then flush sizes should be effectively as they are now.
Later, when a pipeline is instituted, the flush-to-disk size will be whatever
our Segment size is or more even (Segments get added to the pipeline; if
compaction, Segments can be combined). Segments can also run more dense than
CSLS. In general case, a Segment should be as fat as our current file flushes?
> 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, move.to.junit4.patch
>
>
> Implementation of a new compacting memstore with non-optimized immutable
> segment representation
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
