http://img338.imageshack.us/img338/6831/screenshot20130111at949.png
this shows how often we flush, and how large are the region files. We do have bloomfilters turn up, that we don't incur extra seeks across multiple RS files. -Jack On Fri, Jan 11, 2013 at 9:47 AM, Jack Levin <[email protected]> wrote: > We buffer all accesses to HBASE with Varnish SSD based caching layer. > So the impact for reads is negligible. We have 70 node cluster, 8 GB > of RAM per node, relatively weak nodes (intel core 2 duo), with > 10-12TB per server of disks. Inserting 600,000 images per day. We > have relatively little of compaction activity as we made our write > cache much larger than read cache - so we don't experience region file > fragmentation as much. > > -Jack > > On Fri, Jan 11, 2013 at 9:40 AM, Mohit Anchlia <[email protected]> wrote: >> I think it really depends on volume of the traffic, data distribution per >> region, how and when files compaction occurs, number of nodes in the >> cluster. In my experience when it comes to blob data where you are serving >> 10s of thousand+ requests/sec writes and reads then it's very difficult to >> manage HBase without very hard operations and maintenance in play. Jack >> earlier mentioned they have 1 billion images, It would be interesting to >> know what they see in terms of compaction, no of requests per sec. I'd be >> surprised that in high volume site it can be done without any Caching layer >> on the top to alleviate IO spikes that occurs because of GC and compactions. >> >> On Fri, Jan 11, 2013 at 7:27 AM, Mohammad Tariq <[email protected]> wrote: >> >>> IMHO, if the image files are not too huge, Hbase can efficiently serve the >>> purpose. You can store some additional info along with the file depending >>> upon your search criteria to make the search faster. Say if you want to >>> fetch images by the type, you can store images in one column and its >>> extension in another column(jpg, tiff etc). >>> >>> BTW, what exactly is the problem which you are facing. You have written >>> "But I still cant do it"? >>> >>> Warm Regards, >>> Tariq >>> https://mtariq.jux.com/ >>> >>> >>> On Fri, Jan 11, 2013 at 8:30 PM, Michael Segel <[email protected] >>> >wrote: >>> >>> > That's a viable option. >>> > HDFS reads are faster than HBase, but it would require first hitting the >>> > index in HBase which points to the file and then fetching the file. >>> > It could be faster... we found storing binary data in a sequence file and >>> > indexed on HBase to be faster than HBase, however, YMMV and HBase has >>> been >>> > improved since we did that project.... >>> > >>> > >>> > On Jan 10, 2013, at 10:56 PM, shashwat shriparv < >>> [email protected]> >>> > wrote: >>> > >>> > > Hi Kavish, >>> > > >>> > > i have a better idea for you copy your image files to a single file on >>> > > hdfs, and if new image comes append it to the existing image, and keep >>> > and >>> > > update the metadata and the offset to the HBase. Because if you put >>> > bigger >>> > > image in hbase it wil lead to some issue. >>> > > >>> > > >>> > > >>> > > ∞ >>> > > Shashwat Shriparv >>> > > >>> > > >>> > > >>> > > On Fri, Jan 11, 2013 at 9:21 AM, lars hofhansl <[email protected]> >>> wrote: >>> > > >>> > >> Interesting. That's close to a PB if my math is correct. >>> > >> Is there a write up about this somewhere? Something that we could link >>> > >> from the HBase homepage? >>> > >> >>> > >> -- Lars >>> > >> >>> > >> >>> > >> ----- Original Message ----- >>> > >> From: Jack Levin <[email protected]> >>> > >> To: [email protected] >>> > >> Cc: Andrew Purtell <[email protected]> >>> > >> Sent: Thursday, January 10, 2013 9:24 AM >>> > >> Subject: Re: Storing images in Hbase >>> > >> >>> > >> 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 <[email protected] >>> > >>> > >> 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 <[email protected] >>> > >>> > >> wrote: >>> > >>> >>> > >>>> I meant this to say "a few really large values" >>> > >>>> >>> > >>>> On Sun, Jan 6, 2013 at 12:49 PM, Andrew Purtell < >>> [email protected]> >>> > >>>> 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) >>> > >>>> >>> > >> >>> > >> >>> > >>> > >>>
