Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 17 Jul 2015 22:13:09 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12684123.1386803761000.222686.1437171189507@Atlassian.JIRA>
In-Reply-To: <JIRA.12684123.1386803761000@Atlassian.JIRA>
References: <JIRA.12684123.1386803761000@Atlassian.JIRA>
 <JIRA.12684123.1386803761521@arcas>
Subject: [jira] [Issue Comment Deleted] (CASSANDRA-6477) Materialized Views
 (was: Global Indexes)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis updated CASSANDRA-6477:
--------------------------------------
    Comment: was deleted

(was: Let's go back to the basic use case that this is supposed to replace/help/make better.  The case where we want two query tables for the same data.  That is, they have the same primary keys, but different partition keys (and clustering column orders).

Today, I would do this by having a logged batch for the insert and that batch would insert into each of the two query tables.  With this I get some data consistency guarantees.  For example, if the client returns "success", I know that *both* of the inserts were accepted at the desired consistency level.  So, if I did 2 writes at CL_QUORUM, and I receive a "success", then I know I can then do a CL_QUORUM read of *either* table and see the most recent data.

However, with this "asynchronous" MV approach, I no longer get this behavior.  I write to the base table at CL_QUORUM and get the "success" return.  At that point, I can do a CL_QUORUM read from the base table and see the most recent insert.  However, if I do a CL_QUORUM read from the MV, I have no guarantees at all.

This approach does not address the basic situation that we are trying to cover.  That concerns me greatly.
)

> Materialized Views (was: 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 beta 1
>
>         Attachments: test-view-data.sh, users.yaml
>
>
> 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)