Hi Jack, Thanks for the reply.
Each tenant will has around 50-100 tables for their applications. probably log collection, probably account table, it's not fixed and depends on tenants' need. There will be a team in charge of helping tenant to do data modeling and access patterns. Tenants will not directly admin on the cluster, we will take care. Yes, multi-cluster is a solution. But the cost will be quite high, because each tenant's data is far less than the capacity of a 3 node cluster. So I want to put multiple tenants into one clusters. Jack Krupansky <jack.krupan...@gmail.com>于2016年4月6日周三 上午10:41写道： > What is the nature of these tenants? Are they each creating their own data > models? Is there one central authority that will approve of all data models > and who can adjust the cluster configuration to support those models? > > Generally speaking, multi-tenancy is an anti-pattern for Cassandra and for > most servers. The proper way to do multitenancy is to not do it at all, and > to use separate machines or at least separate virtual machines. > > In particular, there needs to be a central authority managing a Cassandra > cluster to assure its smooth operation. If each tenant is going in their > own directions, then nobody will be in charge and capable of assuring that > everybody is on the same page. > > Again, it depends on the nature of these tenants and how much control the > cluster administrator has over them. > > Think of a Cassandra cluster as managing the data for either a single > application or a collection of applications which share the same data. If > there are multiple applications that don't share the same data, then they > absolutely should be on separate clusters. > > > -- Jack Krupansky > > On Tue, Apr 5, 2016 at 5:40 PM, Kai Wang <dep...@gmail.com> wrote: > >> Once a while the question about table count rises in this list. The most >> recent is >> https://groups.google.com/forum/#!topic/nosql-databases/IblAhiLUXdk >> >> In short C* is not designed to scale with the table count. For one each >> table/CF has some fixed memory footprint on *ALL* nodes. The consensus is >> you shouldn't have more than "a few hundreds" of tables. >> >> On Mon, Apr 4, 2016 at 10:17 AM, jason zhao yang < >> zhaoyangsingap...@gmail.com> wrote: >> >>> Hi, >>> >>> This is Jason. >>> >>> Currently, I am using C* 2.1.10, I want to ask what's the optimal number >>> of tables I should create in one cluster? >>> >>> My use case is that I will prepare a keyspace for each of my tenant, and >>> every tenant will create tables they needed. Assume each tenant created 50 >>> tables with normal workload (half read, half write). so how many number >>> of tenants I can support in one cluster? >>> >>> I know there are a few issues related to large number of tables. >>> * frequent GC >>> * frequent flush due to insufficient memory >>> * large latency when modifying table schema >>> * large amount of tombstones during creating table >>> >>> Is there any other issues with large number of tables? Using a 32GB >>> instance, I can easily create 4000 tables with off-heap-memtable. >>> >>> BTW, Is this table limitation solved in 3.X? >>> >>> Thank you very much. >>> >>> >> >
