[
https://issues.apache.org/jira/browse/HBASE-11339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120118#comment-14120118
]
Jonathan Hsieh commented on HBASE-11339:
----------------------------------------
re: [~apurtell]
bq. Please. I don't think we should ever ship a release with a dependency on MR
for core function. Committing this to trunk in stages could be ok, as long as
we do not attempt a release including the feature before MOB compaction is
handled natively.
I agree -- moreover, ideally hbase should not need external processes except
for hdfs/zk.
However, there is what should be and what has happened and what does happen.
In these cases we have ended up marking features experimental. There are many
examples of features in core hbase that shipped in "stable" releases and that
still require external processes and may have no demonstrated users. You'd
have to go back a bit to get one that explicitly depended on MR but they did
exist. (e.g. pre dist log splitting we had a MR based log replay -- useful in
avoiding 10 hr recovery downtimes). This would be a good discussion topic for
an upcoming PMC meeting.
What is your definition of stages? -- do you mean patch a time or something
more like: stage one with external compactions, stage 2 with internal
compactions? For this MOB feature, we would have the experimental tag while we
had external compactions and it would remain until we remove external
dependencies and this compaction harden with fault testing. Give our current
cadence, we should be able have this completed as part of hbase 1.99/2.0 line's
timeframe.
> HBase MOB
> ---------
>
> Key: HBASE-11339
> URL: https://issues.apache.org/jira/browse/HBASE-11339
> Project: HBase
> Issue Type: Umbrella
> Components: regionserver, Scanners
> Reporter: Jingcheng Du
> Assignee: Jingcheng Du
> Attachments: HBase MOB Design-v2.pdf, HBase MOB Design-v3.pdf, HBase
> MOB Design-v4.pdf, HBase MOB Design.pdf, MOB user guide.docx, MOB user
> guide_v2.docx, hbase-11339-in-dev.patch
>
>
> It's quite useful to save the medium binary data like images, documents
> into Apache HBase. Unfortunately directly saving the binary MOB(medium
> object) to HBase leads to a worse performance since the frequent split and
> compaction.
> In this design, the MOB data are stored in an more efficient way, which
> keeps a high write/read performance and guarantees the data consistency in
> Apache HBase.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
