hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11339) HBase MOB
Date Wed, 03 Sep 2014 17:27:54 GMT

    [ 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

View raw message