Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <C86DD960-3491-487B-8549-28714E1B0B74@gmail.com>
References: <CA+k9evHm3HG3U+GLUV57fOYWp2q8TeKbbm2x4mnQAJEG-tu_mA@mail.gmail.com>
 <C86DD960-3491-487B-8549-28714E1B0B74@gmail.com>
From: Sreeram <sreeram.v@gmail.com>
Date: Wed, 7 Sep 2016 19:49:18 +0530
Message-ID: <CA+k9evG3K_u8ENKsDggUMwysmFL=2ay=38h+PpNJ7h+LaoOURQ@mail.gmail.com>
Subject: Re: Maximum limit on HBase cluster size
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=001a113e071c4b0677053beb992f
archived-at: Wed, 07 Sep 2016 14:19:30 -0000

--001a113e071c4b0677053beb992f
Content-Type: text/plain; charset=UTF-8

Hi Ted,

From the link
"Around 50-100 regions is a good number for a table with 1 or 2 column
families. Remember that a region is a contiguous segment of a column
family.".

This number 50-100 regions per table at the level of individual region
server or for the entire cluster ?

Thanks,
Sreeram


On Wed, Sep 7, 2016 at 4:18 PM, Ted Yu <yuzhihong@gmail.com> wrote:

> With properly designed schema, you don't need to split the cluster.
>
> Please see:
> http://hbase.apache.org/book.html#schema
>
> > On Sep 7, 2016, at 1:59 AM, Sreeram <sreeram.v@gmail.com> wrote:
> >
> > Dear All,
> >
> >
> >
> > Looking forward to your views on the maximum limit of HBase cluster size.
> >
> >
> >
> > We are currently designing a HBase cluster and one of the tables
> (designed
> > in wide format) is expected to have roughly 6 billion rows in production
> by
> > 3 years (with an additional 200 million rows getting added each month).
> In
> > addition, we are expecting roughly 250 columns per row.  Expected table
> > data volume is around 250 TB (at end of 3 years, without considering HDFS
> > replication) and growing by 7 TB per month.
> >
> >
> >
> > While we are provisioning the number of nodes based on expected data
> > volume, wanted to check if there are any limits on the number of rows per
> > cluster.
> >
> >
> >
> > Will it be advisable to split the cluster in such situation into two or
> > more independent clusters?  Will there be any impact to the read/write
> > throughput/latency as the table grows over time?
> >
> >
> >
> > Please advise.
> >
> >
> >
> > Regards,
> >
> > Sreeram
>

--001a113e071c4b0677053beb992f--