Are the tenants using the same schema? If so, you might consider using the tenant's ID as part of the primary key for the tables they have in common.
If they're all using different, largish schemas I'm not sure that Cassandra is well suited to that type of multi-tenancy. There's the per overhead memory pre-table and there's that fact that it's difficult to tune a single cluster to handle the different (probably competing) workloads effectively. Mike On Tue, Apr 5, 2016 at 8:40 PM, jason zhao yang <zhaoyangsingap...@gmail.com > wrote: > 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. >>>> >>>> >>> >>
