cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Svihla <rsvi...@datastax.com>
Subject Re: Using Per-Table Keyspaces for Tunable Replication
Date Fri, 12 Dec 2014 17:26:57 GMT
Clarification "keyspace for each" should be "keyspace for cassandra tables
and solr tables"

On Fri, Dec 12, 2014 at 11:25 AM, Ryan Svihla <rsvihla@datastax.com> 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
> 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 <mightye@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.
>
>

-- 

[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.

Mime
View raw message