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] [Comment Edited] (HBASE-11339) HBase MOB
Date Thu, 04 Sep 2014 03:32:52 GMT

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

Jonathan Hsieh edited comment on HBASE-11339 at 9/4/14 3:32 AM:
----------------------------------------------------------------

bq. The master's built in splitting was still available even if there was no MR runtime that
could run the replay tool.

If you were ok with 10 hr downtimes due to recovery (back then no meta first recovery), the
sure.  For large deployments that MR for this was critical and not really optional.

bq. Stage = JIRA issue.

sgtm.

bq. If I read the above correctly we are looking at 2.0 as a possible release for shipping
this feature? I suggest we communicate the feature status as experimental for the whole release
line, i.e. until 2.1, like what we have done with the cell security features in the 0.98 line.

Yes -- trunk is 2.0 and new features should only land in trunk and yes, we would note it as
experimental until all pieces are in and some hardening as taken place. .  Ideally, all major
features would be experimental in their first release. If we follow through with having 2.0
\-> 2.1 be like will be like 0.92 \-> 0.94 or 0.96 \->0.98, then following the cell
security approach for experimental status sounds good to me.

(edit fixed some formatting with accidental -strikethroughs-)



was (Author: jmhsieh):
bq. The master's built in splitting was still available even if there was no MR runtime that
could run the replay tool.

If you were ok with 10 hr downtimes due to recovery (back then no meta first recovery), the
sure.  For large deployments that MR for this was critical and not really optional.

bq. Stage = JIRA issue.

sgtm.

bq. If I read the above correctly we are looking at 2.0 as a possible release for shipping
this feature? I suggest we communicate the feature status as experimental for the whole release
line, i.e. until 2.1, like what we have done with the cell security features in the 0.98 line.

Yes -- trunk is 2.0 and new features should only land in trunk and yes, we would note it as
experimental until all pieces are in and some hardening as taken place. .  Ideally, all major
features would be experimental in their first release. If we follow through with having 2.0
-> 2.1 be like will be like 0.92 -> 0.94 or 0.96->0.98, then following the cell security
approach for experimental status sounds good to me.



> 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, MOB user guide_v3.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)

Mime
View raw message