If I were you, I'd do both. If you're trying to build a multi-tenanted
system, it's probably a better idea to include tenant ID as the partition
key of every cross-tenant table. You can easily run Cassandra with a 4 gig
heap, but I'd never plan on doing so for a production use except for very
sma
so i guess i have to 1) increase the heap size or 2) reduce the number of
keyspaces/column families.
Thanks for you confirmation.
On Tue, May 24, 2016 at 10:08 AM, Eric Stevens wrote:
> Large numbers of tables is generally recommended against. Each table has
> a fixed on-heap memory overhead,
Large numbers of tables is generally recommended against. Each table has a
fixed on-heap memory overhead, and by your description it sounds like you
might have as many as 12,000 total tables when you start running into
trouble.
With such a small heap to begin with, you've probably used up most of
We are exploring cassandra's limit by creating a lot of keyspaces with
moderate number of column families (roughly 40 - 50) per keyspace and we
have a problem after we reach certain amount of keyspaces, that cqlsh
starts to time out when connecting to cassandra.
This is our cassandra setup. We hav
