Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 24 Jun 2015 19:58:04 +0000 (UTC)
From: "Constance Eustace (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12839893.1435078736000.6060.1435175884739@Atlassian.JIRA>
In-Reply-To: <JIRA.12839893.1435078736000@Atlassian.JIRA>
References: <JIRA.12839893.1435078736000@Atlassian.JIRA>
 <JIRA.12839893.1435078736634@arcas>
Subject: [jira] [Updated] (CASSANDRA-9638) Mirrored distribution tables with
 same PK
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Constance Eustace updated CASSANDRA-9638:
-----------------------------------------
    Description: 
CASSANDRA-9231 covers probably most of this...

Many of the problems with CAP and cross-partition data seems to deal with the data not being local across partitions. 

Shouldn't it be possible to provide a mechanism where associated or "child" data gets mapped in the same data distribution pattern as the parent key/table, even in Vnodes?

Certainly if the PK is exactly the same (extension tables or the like). And while schema could technically be centralized in the same rowkey, in reality the "sweet spot" of columns / partition key gets in the way of this. 

It would be super tough mathematically to do the same distribution for PKs that are something like PK: {parentkey, extensionkey) and get that to hash/distribute the same, but that would be nice, but perhaps an expansion of key lookup to calculate "distribution/vnode key that maps to the distribution range, and then an actual lookup key in the node for the actual partition row.


  was:
Many of the problems with CAP and cross-partition data seems to deal with the data not being local across partitions. 

Shouldn't it be possible to provide a mechanism where associated or "child" data gets mapped in the same data distribution pattern as the parent key/table, even in Vnodes?

Certainly if the PK is exactly the same (extension tables or the like). And while schema could technically be centralized in the same rowkey, in reality the "sweet spot" of columns / partition key gets in the way of this. 

It would be super tough mathematically to do the same distribution for PKs that are something like PK: {parentkey, extensionkey) and get that to hash/distribute the same, but that would be nice, but perhaps an expansion of key lookup to calculate "distribution/vnode key that maps to the distribution range, and then an actual lookup key in the node for the actual partition row.


> Mirrored distribution tables with same PK
> -----------------------------------------
>
>                 Key: CASSANDRA-9638
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9638
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Constance Eustace
>
> CASSANDRA-9231 covers probably most of this...
> Many of the problems with CAP and cross-partition data seems to deal with the data not being local across partitions. 
> Shouldn't it be possible to provide a mechanism where associated or "child" data gets mapped in the same data distribution pattern as the parent key/table, even in Vnodes?
> Certainly if the PK is exactly the same (extension tables or the like). And while schema could technically be centralized in the same rowkey, in reality the "sweet spot" of columns / partition key gets in the way of this. 
> It would be super tough mathematically to do the same distribution for PKs that are something like PK: {parentkey, extensionkey) and get that to hash/distribute the same, but that would be nice, but perhaps an expansion of key lookup to calculate "distribution/vnode key that maps to the distribution range, and then an actual lookup key in the node for the actual partition row.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)