[
https://issues.apache.org/jira/browse/HBASE-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219382#comment-15219382
]
Eshcar Hillel commented on HBASE-14920:
---------------------------------------
I recently updated YCSB to support also delete operations.
The delete operations in the benchmark I ran ended up as cells of type
*DeleteFamily*. I would expect tombstones to be of type Delete.
This could be an issue with my YCSB client, so we can ignore this for the
moment.
Anyone else had the same problem before?
What exactly is the affect of a cell of type DeleteFamily in a normal disk
compaction? does it remove all the entries in the column family?
[~anoop.hbase] The patch is in RB (there's a link to it in the Jira).
An in-memory compaction removes entries from the memory, much like a flush to
disk would do.
The only reason to keep records in WAL is when data is *not yet* persistent on
disk.
If we remove data from memory (during in-memory compaction) so it will never
arrive to disk (since a more recent version already exists), no point in
keeping the records in WAL, and it can be removed from it.
To summarize this point, in the case of a compacting memstore tombstones are
not removed during in-memory compaction (this is the equivalent of minor
compaction) and need to wait till they hit the disk to be removed in a major
compaction.
> 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,
> 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)
