[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969254#comment-13969254
]
Anoop Sam John commented on HBASE-10885:
----------------------------------------
bq. Do the delete handling in compaction because for the deleteColumn or
deleteFamily cases if we convert that delete request to a set of per-cell
deletes, this could produce an explosion of tombstones.
+1
bq.If we are not storing visibility expression terminals (LeafExpressionNodes)
in sorted order by ordinal we probably should consider it. (I don't think we
are.) Because e.g. A|B == B|A. It would be most efficient if we can simply do
byte comparison of serialized visibility expressions on the delete marker and
any found while enumerating cells covered by it.
Yes +1.
So when we decide at the compaction time by direct byte compare of expressions
in Delete kv and other kvs, what abt the old HFile data written using 98.0 or
98.1 versions? This will be like not sorted.
Also it wont one simple bytes compare. A&B will be stored as one Tag. In case
of '|' it will be stored as 2 tags. So we need to consider all these tags and
compare all. Just a note before starting the impl.
> Support visibility expressions on Deletes
> -----------------------------------------
>
> Key: HBASE-10885
> URL: https://issues.apache.org/jira/browse/HBASE-10885
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.98.1
> Reporter: Andrew Purtell
> Assignee: ramkrishna.s.vasudevan
> Fix For: 0.99.0, 0.98.2
>
>
> Accumulo can specify visibility expressions for delete markers. During
> compaction the cells covered by the tombstone are determined in part by
> matching the visibility expression. This is useful for the use case of data
> set coalescing, where entries from multiple data sets carrying different
> labels are combined into one common large table. Later, a subset of entries
> can be conveniently removed using visibility expressions.
> Currently doing the same in HBase would only be possible with a custom
> coprocessor. Otherwise, a Delete will affect all cells covered by the
> tombstone regardless of any visibility expression scoping. This is correct
> behavior in that no data spill is possible, but certainly could be
> surprising, and is only meant to be transitional. We decided not to support
> visibility expressions on Deletes to control the complexity of the initial
> implementation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
