[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497102#comment-14497102
]
Carl Yeksigian commented on CASSANDRA-6477:
-------------------------------------------
For counters, we can push to any random replica because we have a shard per
replica and sum them at read time. For the global index update, we're trying to
make sure that simultaneous updates are applied to the table and index in a
serializable order. As such, it wouldn't really work to push the update to any
random replica; if two replicas get pushed competing updates, we end up in the
same situation. Instead, we would need to have a single replica that we push
all index updates through, which would break if the replica dies for any reason.
Also, for the complex tombstones, it would very difficult to determine whether
a grouping of updates indicates simultaneous updates or just a series of
updates that happened to use the same values. For instance, if the user does 24
=> 25 => 26 => 24 => 26 => 25, we would get a bunch of complex tombstones {{24
=> 25}}, {{25 => 26}}, {{26 => 24}}, {{24 => 26}}, {{26 => 25}}. When cleaning
them up, it isn't going to be clear whether we have the case as described
before where 24 is simultaneously updated to 25 and 26, or whether it was a
loop of updates as described here.
> 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)
