With small data size and unknown access pattern, any particular reason to choose C*? It sounds like a relational database fits better.
On Tue, Apr 5, 2016 at 11: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. >>>> >>>> >>> >>
