cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Potekhin <>
Subject Re: Cassandra search performance
Date Mon, 07 May 2012 23:15:17 GMT
Thanks for the comments, much appreciated.


On 5/7/2012 3:22 AM, David Jeske wrote:
> On Sun, Apr 29, 2012 at 4:32 PM, Maxim Potekhin < 
> <>> wrote:
>     Looking at your example,as I think you understand, you forgo
>     indexes by
>     combining two conditions in one query, thinking along the lines of
>     what is
>     often done in RDBMS. A scan is expected in this case, and there is no
>     magic to avoid it.
> This sounds like a mis-understanding of how RDBMSs work. If you 
> combine two conditions in a single SQL query, the SQL execution 
> optimizer looks at the cardinality of any indicies. If it can 
> successfully predict that one of the conditions significantly reduces 
> the set of rows that would be considered (such as a status match 
> having 200 hits vs 1M rows in the table), then it selects this index 
> for the first-iteration, and each index hit causes a record lookup 
> which is then tested for the other conditions.  (This is one of 
> several query-execution types RDBMS systems use)
> I'm no Cassandra expert, so I don't know what it does WRT 
> index-selection, but from the page written on secondary indicies, it 
> seems like if you just query on status, and do the other filtering 
> yourself it'll probably do what you want...
>     However, if this query is important, you can easily index on two
>     conditions,
>     using a composite type (look it up), or string concatenation for
>     quick and
>     easy solution.
> This is not necessarily a good idea. Creating a composite index 
> explodes the index size unnecessarily. If a condition can reduce a 
> query to 200 records, there is no need to have a composite index 
> including another condition.

View raw message