[
https://issues.apache.org/jira/browse/HBASE-22749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895593#comment-16895593
]
Vladimir Rodionov commented on HBASE-22749:
-------------------------------------------
{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)
