cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Patel (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6477) Global indexes
Date Tue, 17 Mar 2015 02:07:42 GMT


Jay Patel commented on CASSANDRA-6477:

Glad to see lot of activities on this ticket recently.  
+1 for write-only/read-write index switch. This can simplify multiple Ops tasks including
implementing “online" index rebuild.

>From the code, looks like currently all de-norm/include columns are added as regular columns
in the GI index table. Later on (as a different ticket?), how about allowing user to define
some include columns as “sort columns”, which we can add as clustering columns in the
index table to support sorting and range queries (on sort columns). However, the sort columns
need to be defined upfront. And, adding/removing sort columns can require rebuilding index.
Or, any better idea to support ordering/range queries?

We’ve built similar generic GI framework at the client side which supports ordering/range
queries/multi-columns/collections/etc. But eventually, it makes sense to use C* GI capabilities
once available. To contribute to these GI efforts, should we wait until the first cut gets
merge to master? or, can fork from ticket/6477-2?

Question: Regarding the Benedict’s concurrent update suggestion (01/Apr/14), just want to
confirm that it will work for concurrent updates in case of multi-dc set up with local quorum.
I think index may be inaccurate initially, but eventually get corrected as primary data replicates
across data centers. Currently, we're solving this concurrency & stale index issue by
async read-repair for the index (sort of similar to what C* does to fix replicas). 


> Global indexes
> --------------
>                 Key: CASSANDRA-6477
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Carl Yeksigian
>              Labels: cql
>             Fix For: 3.0
> Local indexes are suitable for low-cardinality data, where spreading the index across
the cluster is a Good Thing.  However, for high-cardinality data, local indexes require querying
most nodes in the cluster even if only a handful of rows is returned.

This message was sent by Atlassian JIRA

View raw message