On Fri, Dec 12, 2014 at 4:50 PM, Eric Stevens wrote:
>
> I know that Thrift includes keyspace as part of the connection details, so
> if you're reading or writing to many keyspaces, you'll end up having to
> make a lot of additional round trips, and it will hurt your throughput. I
> may be wrong
Well we started with the thought that we'd have two keyspaces, one for
searchables and one for non-searchables like you mentioned. But our
concern is that we may change our mind about what column families are
available for search in the future. Separate keyspaces per table give us
greater flexibi
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
Clarification "keyspace for each" should be "keyspace for cassandra tables
and solr tables"
On Fri, Dec 12, 2014 at 11:25 AM, Ryan Svihla wrote:
>
> 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
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
