hbase-issues mailing list archives

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

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

Anoop Sam John commented on HBASE-14227:
----------------------------------------

It is not that straight forward change.  When we call compact <table> <cf> there
is a column family for the (normal HBase cf) reference cells which refers to MOB cells.  And
there is another MOB CF. A compaction on the MOB CF will be more IO oriented than the normal
CFs.  So when we call compact whether the compaction has to happen for the ref CF or MOB CF
or both?  May be instead of new APIs as above, it would have been like overloaded APIs with
a boolean param which says whether to compact/major compact the MOB CF also?  Then there is
no need for new CP hooks and the security checks also can be enforced.

> 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
APIs.
> 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
(v6.3.4#6332)

Mime
View raw message