Secondary Index Limitation / DOes it exist in Cassandra 1.1.2

[Arya Goudarzi <go...@gmail.com>]

Hi All,

Correct me if I am wrong, but I know that secondary indexes are stored
to local column families on each node. Previously where the default
cache key value was 200,000 rows, and you couldn't really tune the
local index column family, that posed a limitation on low cardinality
of the possible values of the secondary index column. However, in
Cassandra 1.1.2, I don't see the option of tuning cache per row count
any more and it is solely memory based. I wonder if this eliminates he
previous limitations with secondary indexes.

Please advice.

Cheers,
-Arya

Re: Secondary Index Limitation / DOes it exist in Cassandra 1.1.2

[Tyler Hobbs <ty...@datastax.com>]

That's only a small part of the problem.  A larger issue is that what
follows the index read is basically a multiget within that node, which
generates a lot of non-sequential I/O.  The second issue is that nodes are
queried sequentially to get more result rows until the requested row count
has been reached.  So, if each node only has a handful of matching rows,
you'll end up querying every node in the cluster (more or less) to answer
the query.

On Tue, Jul 31, 2012 at 8:44 PM, Arya Goudarzi <go...@gmail.com> wrote:

> I know that secondary indexes are stored
> to local column families on each node. Previously where the default
> cache key value was 200,000 rows, and you couldn't really tune the
> local index column family, that posed a limitation on low cardinality
> of the possible values of the secondary index column. However, in
> Cassandra 1.1.2, I don't see the option of tuning cache per row count
> any more and it is solely memory based. I wonder if this eliminates he
> previous limitations with secondary indexes.
>



-- 
Tyler Hobbs
DataStax <http://datastax.com/>