hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohammad Tariq <donta...@gmail.com>
Subject Re: Storing images in Hbase
Date Thu, 10 Jan 2013 19:24:26 GMT
Jack, Leonid,

    I request you guys to please continue the discussion
through the thread itself if possible for you both. I would
like to know about Jack's setup. I too find it quite interesting.

Many thanks.

Warm Regards,
Tariq
https://mtariq.jux.com/


On Fri, Jan 11, 2013 at 12:50 AM, Leonid Fedotov
<lfedotov@hortonworks.com>wrote:

> Jack,
> yes, this is very interesting to know your setup details.
> Could you please provide more information?
> Or we can take this off the list if you likeā€¦
>
> Thank you!
>
> Sincerely,
> Leonid Fedotov
>
> On Jan 10, 2013, at 9:24 AM, Jack Levin wrote:
>
> > We stored about 1 billion images into hbase with file size up to 10MB.
> > Its been running for close to 2 years without issues and serves
> > delivery of images for Yfrog and ImageShack.  If you have any
> > questions about the setup, I would be glad to answer them.
> >
> > -Jack
> >
> > On Sun, Jan 6, 2013 at 1:09 PM, Mohit Anchlia <mohitanchlia@gmail.com>
> wrote:
> >> I have done extensive testing and have found that blobs don't belong in
> the
> >> databases but are rather best left out on the file system. Andrew
> outlined
> >> issues that you'll face and not to mention IO issues when compaction
> occurs
> >> over large files.
> >>
> >> On Sun, Jan 6, 2013 at 12:52 PM, Andrew Purtell <apurtell@apache.org>
> wrote:
> >>
> >>> I meant this to say "a few really large values"
> >>>
> >>> On Sun, Jan 6, 2013 at 12:49 PM, Andrew Purtell <apurtell@apache.org>
> >>> wrote:
> >>>
> >>>> Consider if the split threshold is 2 GB but your one row contains 10
> GB
> >>> as
> >>>> really large value.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>>
> >>>   - Andy
> >>>
> >>> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> >>> (via Tom White)
> >>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message