http://www.datastax.com/support-forums/topic/per-tenant-keyspaces-and-multi-tenancy Software, Support, and Training for Apache Cassandra en-US Thu, 20 Jun 2013 03:46:01 +0000 http://bbpress.org/?v=1.0.3 q http://www.datastax.com/support-forums/search.php http://www.datastax.com/support-forums/topic/per-tenant-keyspaces-and-multi-tenancy#post-1956 Mon, 21 May 2012 23:58:08 +0000 jas 1956@http://www.datastax.com/support-forums/ <p>I think someone with more experience with Cassandra internals can provide the nitty-gritty differences for your three scenarios. My understanding is that with Cassandra 1.x (perhaps even with 0.8x) that the overhead in creating and maintaining a keyspace is fairly minimal, and that it should not weigh in in your deciding between your scenarios 1 and 2.</p> <p>Also, there are keyspace specific attributes, most notably the placement strategy and other strategy options, including the replication factor and data centers. If metadata and the keyspace level is expected to be the same for all tenants, then you can still go with either option 1 or 2. But, a separate keyspace keeps things a little cleaner in my opinion instead incorporating a tenant's name or other ID into the naming of the column families.</p> <p>For my current project, I like the cleanliness of a separate keyspace per tenant. Also, I intend to make use of keyspace level config. Perhaps a larger tenant would be better served with a higher replication factor? Or perhaps their content will be replicated to specific data centers. Another tenant may have, say, no presence in Asia, so why replicate their content there? </p> <p>I did not even consider your scenario 3. In my case, tenant content is updated very infrequently. My plan is record for some time interval, whether or not an update was made in a particular tenant CF. If so, then it will be snapshot and backed up. If you have multiple tenants' content in a single CF, this gets complicated. Also, if you terminate your relationship with a tenant and want to delete their data, you will have to delete all tenant specific rows, rather than just drop some number of CFs or an entire keyspace.</p> <p>Don't know if this is useful or not, but I wanted to explain some of my reasoning.</p> <p>Good luck!</p> <p>Jeff </p> http://www.datastax.com/support-forums/topic/per-tenant-keyspaces-and-multi-tenancy#post-1938 Fri, 18 May 2012 15:14:44 +0000 Anonymous 1938@http://www.datastax.com/support-forums/ <p>To clarify the question:</p> <p>What are the pros and cons of implementing multi-tenancy with:</p> <ol> <li>Keyspace per tenant</li> <li>Set of column families per tenant in a single keyspace</li> <li>Tenant name as part of rowkey or column name in a single set of column families</li> </ol> http://www.datastax.com/support-forums/topic/per-tenant-keyspaces-and-multi-tenancy#post-1936 Fri, 18 May 2012 04:21:02 +0000 Anonymous 1936@http://www.datastax.com/support-forums/ <p>Are per-tenant keyspaces a good way to implement multi-tenancy with Cassandra? My application has a small number of column families per tenant. One way to implement this would be a keyspace per tenant. However I have heard that:</p> <p>- a large number of keyspaces could cause memory issues<br /> - frequently switching keyspaces could impact performance and prevent optimization of the connection pool</p> <p>Are these still valid concerns with Cassandra 1.1? Would it be better to implement tenancy by including tenant in a composite rowkey or column name? </p>