[jira] [Commented] (HBASE-22749) HBase MOB 2.0

["Sean Busbey (JIRA)" <ji...@apache.org>]

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

Sean Busbey commented on HBASE-22749:
-------------------------------------

{quote}
bq. Why is it called MOB 2.0? Seems to be just a change in compaction. Can we have a true 2.0? Streaming/Chunking of big values writing smaller more hbase-friendly Cells that client aggregates rather than the big-Cell abuse that currently is MOB?

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}

Could we do things incrementally? I'd much rather we focus on this refactoring of MOB file accounting and compactions without also throwing in other concerns at the same time. There's nothing about the proposal here that necessitates keeping an implementation from releases e.g. while a change like streaming access to MOB data is outstanding.

If that's easiest for folks to get behind if we refer to the effort on this jira as "MOB compaction refactoring" or "distributed MOB compactions" instead of "MOB 2.0", could we do that?

> 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.1.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)