hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Maximum limit on HBase cluster size
Date Wed, 07 Sep 2016 14:39:44 GMT
This should be per region server.

Cheers

On Wed, Sep 7, 2016 at 7:19 AM, Sreeram <sreeram.v@gmail.com> wrote:

> 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
> >
>

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