Most people are better served building multiple clusters and spending their engineering time optimizing for maintaining multiple clusters, vs spending their engineering time learning how to work around the sharp edges that make large shared clusters hard.
Large multi-tenant clusters give you less waste and a bit more elasticity (one tenant can burst and use spare capacity that would typically be left for the other tenants). However, one bad use case / table can ruin everything (one bad read that generates GC hits all use cases), and eventually certain mechanisms/subsystems dont scale past certain points (e.g. schema - large schemas and large clusters are much harder than small schemas and small clusters) On Fri, Nov 12, 2021 at 11:31 AM S G <sg.online.em...@gmail.com> wrote: > Hello, > > Is there any case where we would prefer one big giant cluster (with > multiple large tables) over several smaller clusters? > Apart from some management overhead of multiple Cassandra Clients, it > seems several smaller clusters are always better than a big one: > > 1. Avoids SPOF for all tables > 2. Helps debugging (less noise from all tables in the logs) > 3. Traffic spikes on one table do not affect others if they are in > different tables. > 4. We can scale tables independently of each other - so colder data > can be in a smaller cluster (more data/node) while hotter data can be on a > bigger cluster (less data/node) > > > It does not mean that every table should be in its own cluster. > But large ones can be moved to their own dedicated clusters (like those > more than a few terabytes). > And smaller ones can be clubbed together in one or few clusters. > > Please share any recommendations for the above from actual production > experiences. > Thanks for helping ! > >
