[
https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701883#comment-15701883
]
Anastasia Braginsky commented on HBASE-17081:
---------------------------------------------
Hi [~anoop.hbase],
Thanks for your review and comments!
I understand your concern that CompositeImmutableSegment is not truly some new
type of Segment, but actually a wrap around a list of ImmutableSegments.
However, this way we can (in majority of cases) encapsulate the composition of
segments inside the snapshot. The CompactingMemStore (or any MemStore) should
not be aware how exactly snapshot is implemented. I know this is not always
true, and this is due to getCellSet(), because to create a single CellSet out
of N segments will be too costly. But it would be wrong, to not to encapsulate
at all just because we cannot encapsulate it always.
So what you suggest is just to define snapshot as a List<ImmutableSegment> in
the CompactingMemStore and then to deal with this list in the memstore code?
We believe it would be a bad engineering practice.
Or do I understand you wrongly?
> 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,
> HBASE-17081-V03.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)
