cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eax Melanhovich <m...@eax.me>
Subject Re: A few stupid questions...
Date Wed, 27 May 2015 04:56:21 GMT
Thank you!

On Tue, 26 May 2015 15:45:01 -0500
Tyler Hobbs <tyler@datastax.com> wrote:

> On Tue, May 26, 2015 at 2:00 PM, Eax Melanhovich <mail@eax.me> wrote:
> 
> >
> > First. Lets say I have a table (field1, field2, field3, field4),
> > where (field1, field2) is a primary key and field1 is partition
> > key. There is a secondary index for field3 column. Do I right
> > understand that in this case query like:
> >
> > select ... from my_table where field1 = 123 and field3 > '...';
> >
> > ... would be quite efficient, i.e. request would be send only to one
> > node, not the whole cluster?
> >
> 
> You are correct that it would only query one node (or one set of
> replicas, if RF > 1 and CL > 1) due to the partition key being
> restricted.  However, using '>' for the operator on the indexed
> column forces Cassandra to scan the partition instead of using the
> index, because secondary indexes only support '=' operations.  If you
> care about performance, you're probably better off creating a
> dedicated table to serve this type of query, as described here:
> http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling
> 
> 
> >
> > Second. Lets say there is some data that almost never changes but is
> > read all the time. E.g. information about smiles in social network.
> > Or current sessions. In this case would Cassandra cache "hot" data
> > in memtable? Or such data should be stored somewhere else, i.e.
> > Redis or Couchbase?
> 
> 
> Memtables are only used for buffering writes, not for caching read
> data. Cassandra does have several layers of caching though.
> Frequently read data will end up in the key cache and the OS page
> cache, making reads quite efficient.  Optionally, you can also enable
> the row cache.  Since you're almost never modifying the data, the row
> cache is actually a decent fit, although I recommend testing it
> heavily with your use case for stability. The best way to find out if
> your performance is good enough is to benchmark it with your own
> usecase.
> 
> 



-- 
Best regards,
Eax Melanhovich
http://eax.me/

Mime
View raw message