hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jingcheng Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
Date Tue, 18 Aug 2015 09:47:46 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701014#comment-14701014

Jingcheng Du commented on HBASE-14227:

No need for region level, just need to tell table and CF name. The thing is we don't want
to do the compaction in store files and mob files together.
The ref cells of mob are stored in store file in hbase, and the real mob data are stored in
mob files outside hbase directory.
The hbase compaction only needs to compact the ref cells, and mob compaction takes care of
mob files.
The impact of the number of mob files is not significant in read, usually they are deleted
when expired. Sometimes the compactions to them are not necessary.
We have two approaches for this.
# Use a special name format in the cf name, if we want to do the mobCompact, we can pass in
a special cf name, for instance cf$MOB.
# Add two new APIs with one additional parameter (enum or boolean) to switch the mob compaction
and normal compaction.

> Fold special cased MOB APIs into existing APIs
> ----------------------------------------------
>                 Key: HBASE-14227
>                 URL: https://issues.apache.org/jira/browse/HBASE-14227
>             Project: HBase
>          Issue Type: Task
>          Components: mob
>    Affects Versions: 2.0.0
>            Reporter: Andrew Purtell
>            Priority: Blocker
>             Fix For: 2.0.0
> There are a number of APIs that came in with MOB that are not new actions for HBase,
simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them into existing
> We definitely don't need one method for a singleton and another for collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on
a table or not should be largely an internal detail. Exposing as schema option would be fine,
this conforms to existing practice for other features.
> Marking critical because I think removing the *Mob special cased APIs should be a precondition
for release of this feature either in 2.0 or as a backport.

This message was sent by Atlassian JIRA

View raw message