[ https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364422#comment-14364422 ]
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). Thanks! > Global indexes > -------------- > > Key: CASSANDRA-6477 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6477 > 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 (v6.3.4#6332)