It would make more sense to just have a keyspace for each. Something like solr_tables, and cassandra_tables. I've done similar with most customers using DSE search (not a DSE mailing list, but the information is interesting background for your question).
there is a cost to each keyspace and you'll hit a level where the cost of managing each keyspace gets expensive for your total heap usage (your mileage may vary on lots of factors.). Breaking up keyspaces into logical replication groups makes the most sense from a maintainability and performance standpoint. On Fri, Dec 12, 2014 at 11:21 AM, Eric Stevens <migh...@gmail.com> wrote: > > We're considering moving to a model where we put each of our tables in a > dedicated keyspace. This is so we can tune replication per table, and > change our mind about that replication on a per-table basis without a major > migration. The biggest driver for this is Solr integration, we want to > tune RF into our Solr DC such that only tables which we want to search are > sent there (using NetworkTopologyStrategy with 'solr': 0 for tables which > are not searchable). > > Has anyone else tried this, is there any reason we might not want to do > so? Any hidden gotchas we should be concerned about? Our total table > count is small, in the tens range; our searchable tables are maybe 4 or 5. > -- [image: datastax_logo.png] <http://www.datastax.com/> Ryan Svihla Solution Architect [image: twitter.png] <https://twitter.com/foundev> [image: linkedin.png] <http://www.linkedin.com/pub/ryan-svihla/12/621/727/> DataStax is the fastest, most scalable distributed database technology, delivering Apache Cassandra to the world’s most innovative enterprises. Datastax is built to be agile, always-on, and predictably scalable to any size. With more than 500 customers in 45 countries, DataStax is the database technology and transactional backbone of choice for the worlds most innovative companies such as Netflix, Adobe, Intuit, and eBay.
