CODEWITHSUNDEEP
cassandra
Priti Chandan
Priti Chandan

Reputation: 13

Cassandra - Keyspace level Multi Tenancy

I am working on multi-tenant application, where currently we do have row key based multi-tenancy and it has been working well with us.

Recently we have a requirement where we want to separate storage for each tenant, so we are planning to have separate keyspace for each tenant to hold tenant specific data.

When we were validating our choice of having keyspace/tenant, we came across many posts which says this can cause performance implications, also we didn't really find anyone who says we have implemented keyspace level multi tenancy.

Our cluster is gonna hold approximately 2k tenants. So there will be 2k keyspaces in a cluster, wherein each keyspace will have around 10 column families. What performance implications this design could have?

Upvotes: 1

Views: 569

Answers (1)

M P
M P

Reputation: 300

Having 20,000 tables can cause you troubles in many areas,

  1. Compaction will be slow and often fail.
  2. Repair services will run for very long period and unpredictable time.
  3. Memory requirement will be high and can cause troubles with JVM Heap.

Other than those there are some other concerns - such as in future if at all there is a requirement for a Schema change it will be very hard to implement in production.

May be to keep a logical separation would be better idea - for example not create keyspace per tenant but creating a fixed number of keyspaces (controlled and smaller number) and have multiple tenants (some way related) in same keyspace if really want to move away from row level.

https://docs.datastax.com/en/dse-planning/doc/planning/planningAntiPatterns.html - This explains having too many tables in the anti-pattern.

Upvotes: 3

Related Questions