structural/architectural change, I thought it would
be worth "getting it right" before I have lots of tenants and their data in the
system.
Thank you everyone!
Otis
> HTH
>
> -Mike
>
>
> > Date: Thu, 17 Mar 2011 10:38:11 -0700
> > From: otis_gospodne...@
On Wed, Mar 16, 2011 at 11:30 PM, Otis Gospodnetic
wrote:
> If I'm reading http://hbase.apache.org/book/schema.html#number.of.cfs
> correctly,
> the advice is not to have more than 2-3 CFs per table?
> And what happens if I have say 6 CFs per table?
>
> Again if I read the above page correctly, t
700
> From: otis_gospodne...@yahoo.com
> Subject: Re: Suggested and max number of CFs per table
> To: user@hbase.apache.org
>
> Hi,
>
>
> > Patrick,
> >
> > Perhaps I misunderstood Otis' design.
> >
> > I thought he'd create the CF ba
tly, it means that it will cause all
other
CFs' files to split (even if they are not big enough yet), which means more
disk
and network IO.
That is, if all those CFs are in the same table. If they are in different
tables then this would not happen?
Thanks,
Otis
> > Date: Thu,
l of the CFs are affected and
split as well?
Thx
-Mike
> Date: Thu, 17 Mar 2011 11:26:35 -0400
> Subject: Re: Suggested and max number of CFs per table
> From: patr...@cloudera.com
> To: user@hbase.apache.org
> CC: otis_gospodne...@yahoo.com
>
> Otis,
>
> Perhaps your
Otis,
Perhaps your biggest issue will be the need to disable the table to add a
new CF. So effectively you need to bring down the application to move in a
new tenant.
Another thing with multiple CFs is that if one CF tends to get
disproportionally more data, you will get a lot of region splitting
30:14 -0700
> From: otis_gospodne...@yahoo.com
> Subject: Suggested and max number of CFs per table
> To: user@hbase.apache.org
>
> Hi,
>
> My Q is around the suggested or maximum number of CFs per table (see
> http://hbase.apache.org/book/schema.html#number.of.cfs )
&
Hi,
My Q is around the suggested or maximum number of CFs per table (see
http://hbase.apache.org/book/schema.html#number.of.cfs )
Consider the following use-case.
* A multi-tenant system.
* All tenants write data to the same table.
* Tenants have different data retention policies.
For the above
