[
https://issues.apache.org/jira/browse/HBASE-11339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120899#comment-14120899
]
Lars Hofhansl commented on HBASE-11339:
---------------------------------------
bq. I'm confused. Section 4.1.2 part this split was assumed and the different
mechanisms were for handling the "large ones".
Let's not ride that point. To me it was not clear that that was implied.
bq. Rough thresholds would be 0-100k hbase by value, 100k-10MB hbase by mob,
10MB+ hbase by ref to hdfs.
Still not happy to introduce all of this for this "small" band of size.
In any case, thanks for indulging me. I realize it's frustrating. Let me change
my vote to -0 :)
I do strongly prefer if we could build the entire thing out (including non-MR
compactions, and tests, etc) in a feature branch, so it's complete before it's
checked in. Any objections to that? Overkill?
> 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)
