Thanks for the comments, much appreciated.
Maxim
On 5/7/2012 3:22 AM, David Jeske wrote:
On Sun, Apr 29, 2012 at 4:32 PM, Maxim Potekhin <[email protected]
<mailto:[email protected]>> 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...
http://www.datastax.com/dev/blog/whats-new-cassandra-07-secondary-indexes
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.
