hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Buttler, David" <buttl...@llnl.gov>
Subject RE: HBase region size
Date Tue, 28 Jun 2011 17:12:31 GMT
My understanding is the following (which will hopefully be corrected by those with more experience):
* you should try to limit your cell size to less than 1 MB.  This is not a hard and fast rule,
but there are certain limits you don't want to exceed: you don't want a row exceeding your
region size.  If you only have only CF/column holding a single 5MB object, then you should
be fine.

* the larger your region size, the less overhead there is for storage, and the fewer total
regions you will need.  The drawback is that random access will be slower.  Given your object
size and the assumption that this is archival storage, you might want to consider a 4GB region

* for standard HDFS, you should aim to keep the total number of files less than 50M.  This
argues for the larger region sizes as well.  With a 4GB region size, one HFile per region,
you could store a maximum of 200PB in HBase.  A 256MB region size would drop your maximum
to closer to 1 PB.  Given all of the other overhead that maximum doesn't consider, larger
sizes are again preferred.

Your other questions are highly dependent on usage patterns that I can't even guess at.  As
a general rule of thumb, I would say go with 1 core for 1-4 disk spindles (depending on your
estimated CPU usage).  Think carefully about where you bottlenecks (disk / network / CPU)
are likely to be and then test out your assumptions.


-----Original Message-----
From: Aditya Karanth A [mailto:aditya_karanth@mindtree.com] 
Sent: Monday, June 27, 2011 11:38 PM
To: hbase-user@hadoop.apache.org
Subject: HBase region size


  We have been using Hadoop in our project as a DFS cluster to store some
critical information.
This critical information is stored as zip files of about 3-5 MB in size
each. The number of these files would grow to more than a billion files and
more than 1 peta byte of storage. We are aware of the “too many small files”
problem in HDFS and hence have considered moving to HBase to store these
files for the following reasons:
1. Indexed reads. Also, this information is archived data, which will not be
read very often.
2. The Regions managed by HBase would help ensure that we don’t end up
having too many files on the DFS.

In order to move from a HDFS to an HBase cluster, we are considering to have
the following setup, we would require someone to validate the same and let
us know of better configurations if any:

1. The setup would have a 20 node HBase cluster.
2. The Hbase region size would be 256 MB.
3. Each datanode to have atleast 32 TB (Tera Bytes) of disk space. (We may
add more data nodes to accomodate > 1PB)

> The question here is, if we have a region size of 256MB, will we still
> have a problem of "too many small files" in the Hadoop for the number of
> regions it may start generating. 
What is the optimum size of the region to go with, given the above scenario?
Given that, we may not be accessing the HBase cluster in a highly concurrent
environment, can we increase the region size.

> I have heard that bigger the size of the regionserver, more time it takes
> for region splitting and slower the reads are. Is this true?
(I have not been able to experiment with all these in our environments yet,
but if anyone has been there and done that, would be good to know)

> Is it good to have smaller clusters with larger disk spaces or have more
> number of clusters with lesser diskspaces?

Any help appreciated.

Thanks & Regards,
View this message in context: http://old.nabble.com/HBase-region-size-tp31943719p31943719.html
Sent from the HBase User mailing list archive at Nabble.com.

View raw message