cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jeske <>
Subject Re: Cassandra search performance
Date Mon, 07 May 2012 07:22:11 GMT
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

View raw message