cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6477) Global indexes
Date Wed, 15 Apr 2015 22:06:02 GMT

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

Mime
View raw message