[
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)
