Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Date: Wed, 27 May 2015 07:56:21 +0300
From: Eax Melanhovich <mail@eax.me>
To: Tyler Hobbs <tyler@datastax.com>
Cc: user@cassandra.apache.org
Subject: Re: A few stupid questions...
Message-ID: <20150527075621.43b85d9b@fujitsu>
In-Reply-To: 
 <CAAam9ssgTprX-yv9mbr-nU-b-w=dONHmxgmgULC4OwQJdPFtow@mail.gmail.com>
References: <20150526220045.186b2b2d@fujitsu>
	<CAAam9ssgTprX-yv9mbr-nU-b-w=dONHmxgmgULC4OwQJdPFtow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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/