[jira] [Comment Edited] (HBASE-22749) HBase MOB 2.0

["Vladimir Rodionov (JIRA)" <ji...@apache.org>]

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

Vladimir Rodionov edited comment on HBASE-22749 at 7/29/19 9:28 PM:
--------------------------------------------------------------------

{quote}
Why is it called MOB 2.0? Seems to be just a change in compaction.
{quote}

Compaction changes are just first step. Yes, we are collecting feedback from the community for features to add/change in MOB, such as already mentioned - streaming access to MOB data.

{quote}
There is no more special compactor for MOB files,  but the class that is doing the compaction is named DefaultMobStoreCompactor; i.e. a compactor that is 'default' but for 'MOB'?
{quote}

DefaultMobStoreCompactor does not do MOB compactions in original MOB - PartitionedMobCompactor does, which is gone now as all the mob.compactions sub-package. 
{quote}
On #3, to compact MOB, need to submit a major_compaction request. Does that mean we major compact all in the target table – MOB and other files? Can I do one or the other (MOB or HFiles). 
{quote}

We are still considering support for *CompactType.MOB*. If there is request to support that we will add it. In this case to start MOB compaction, user must submit *major_compact* with type=CompactType.MOB request. 

Upd.

Having thought about this - no it is not possible major compact only MOB files. The CompactType.MOB request will have to compact both MOB and regular store files and CompactType.NORMAL will compact only store files. This change can be added.  

{quote}
After finishing 'Unified Compactor' section, how does this differ from what was there before? Why superior?
{quote}

Code reduction and unification is an advantage as well. But the overall "superiority" comes from overall MOB 2.0 feature - not from Unified compactor along. We describe the advantages in the design document.  


was (Author: vrodionov):
{quote}
Why is it called MOB 2.0? Seems to be just a change in compaction.
{quote}

Compaction changes are just first step. Yes, we are collecting feedback from the community for features to add/change in MOB, such as already mentioned - streaming access to MOB data.

{quote}
There is no more special compactor for MOB files,  but the class that is doing the compaction is named DefaultMobStoreCompactor; i.e. a compactor that is 'default' but for 'MOB'?
{quote}

DefaultMobStoreCompactor does not do MOB compactions in original MOB - PartitionedMobCompactor does, which is gone now as all the mob.compactions sub-package. 
{quote}
On #3, to compact MOB, need to submit a major_compaction request. Does that mean we major compact all in the target table – MOB and other files? Can I do one or the other (MOB or HFiles). 
{quote}

We are still considering support for *CompactType.MOB*. If there is request to support that we will add it. In this case to start MOB compaction, user must submit *major_compact* with type=CompactType.MOB request.

{quote}
After finishing 'Unified Compactor' section, how does this differ from what was there before? Why superior?
{quote}

Code reduction and unification is an advantage as well. But the overall "superiority" comes from overall MOB 2.0 feature - not from Unified compactor along. We describe the advantages in the design document.  

> HBase MOB 2.0
> -------------
>
>                 Key: HBASE-22749
>                 URL: https://issues.apache.org/jira/browse/HBASE-22749
>             Project: HBase
>          Issue Type: New Feature
>          Components: mob
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>            Priority: Major
>         Attachments: HBase-MOB-2.0-v1.pdf, HBase-MOB-2.0-v2.pdf
>
>
> There are several  drawbacks in the original MOB 1.0  (Moderate Object Storage) implementation, which can limit the adoption of the MOB feature:  
> # MOB compactions are executed in a Master as a chore, which limits scalability because all I/O goes through a single HBase Master server. 
> # Yarn/Mapreduce framework is required to run MOB compactions in a scalable way, but this won’t work in a stand-alone HBase cluster.
> # Two separate compactors for MOB and for regular store files and their interactions can result in a data loss (see HBASE-22075)
> The design goals for MOB 2.0 were to provide 100% MOB 1.0 - compatible implementation, which is free of the above drawbacks and can be used as a drop in replacement in existing MOB deployments. So, these are design goals of a MOB 2.0:
> # Make MOB compactions scalable without relying on Yarn/Mapreduce framework
> # Provide unified compactor for both MOB and regular store files
> # Make it more robust especially w.r.t. to data losses. 
> # Simplify and reduce the overall MOB code.
> # Provide 100% compatible implementation with MOB 1.0.
> # No migration of data should be required between MOB 1.0 and MOB 2.0 - just software upgrade.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)