Return-Path: 
 <user-return-30735-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-user-archive@www.apache.org
Delivered-To: apmail-cassandra-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 00AD4D2E0
	for <apmail-cassandra-user-archive@www.apache.org>;
 Fri, 21 Dec 2012 13:53:54 +0000 (UTC)
Received: (qmail 56840 invoked by uid 500); 21 Dec 2012 13:53:51 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 56747 invoked by uid 500); 21 Dec 2012 13:53:51 -0000
Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@cassandra.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@cassandra.apache.org>
List-Post: <mailto:user@cassandra.apache.org>
List-Id: <user.cassandra.apache.org>
Reply-To: user@cassandra.apache.org
Delivered-To: mailing list user@cassandra.apache.org
Received: (qmail 56727 invoked by uid 99); 21 Dec 2012 13:53:50 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Dec 2012 13:53:50 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of aventurella@gmail.com
 designates 209.85.214.170 as permitted sender)
Received: from [209.85.214.170] (HELO mail-ob0-f170.google.com)
 (209.85.214.170)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 21 Dec 2012 13:53:45 +0000
Received: by mail-ob0-f170.google.com with SMTP id wp18so4613553obc.29
        for <user@cassandra.apache.org>; Fri, 21 Dec 2012 05:53:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:date:message-id:subject:from:to:content-type;
        bh=AwmlD8DNrkHcUHk0Z7R6CqaeU/nEnWdTTP++vibOunI=;
        b=P6hIwGR8Pjb6Y00cIvw+iPxGJAsPhMY3M1bJIGZwlsyFnD47zy/ZgD/tyjuZ3uTzDC
         KjZ5JhYh1aJ0HUY4H4fAJTJ4Ua3Hens1P222p2v77fqdv6GyIOfQinVsm4+ufGEJlwYj
         yl8sEtxkRSYyRlUJD8i1vt1K44ZgXDuhqdrEIs+KUc2cW5n7PdmTPJqEcwHiwVOP3j9v
         ehq0F4Gvs+tGzPI5ilvqbruW3X1VuS1N21SC/s1Xq3ssuzRgbFGv3En1ifRPR7PnhYWW
         hFQXElmzv4bky45T4hqtc1yvtQLJRFWafK7FMZTQQGbvB2Nl8CeOBbTGQSzJQ8oAC13K
         KU9g==
MIME-Version: 1.0
Received: by 10.182.152.2 with SMTP id uu2mr7361372obb.35.1356098004968; Fri,
 21 Dec 2012 05:53:24 -0800 (PST)
Received: by 10.76.34.40 with HTTP; Fri, 21 Dec 2012 05:53:24 -0800 (PST)
Date: Fri, 21 Dec 2012 05:53:24 -0800
Message-ID: 
 <CAP-hOzkLmk6isZCt_t5pwPPgb-8HN=XkV5cz5bkEd8fe8JkowQ@mail.gmail.com>
Subject: CQL3 Compound Primary Keys - Do I have the right idea?
From: Adam Venturella <aventurella@gmail.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=f46d0444ecf3dde69304d15d2b58
X-Virus-Checked: Checked by ClamAV on apache.org

--f46d0444ecf3dde69304d15d2b58
Content-Type: text/plain; charset=ISO-8859-1

Trying to better grasp compound primary keys and what they are conceptually
doing under the hood. When you create a table with a compound primary key
in cql3 (http://www.datastax.com/dev/blog/schema-in-cassandra-1-1) the
first part of the key is the partition key. I get that and the subsequent
parts help with the row name as I understand it.

So when you add a new row to that columnfamily/table, you are still adding
a row. In other words, the RandomPartitioner places it somewhere in the
cluster as a row on it's own as opposed to just adding a new column to an
existing row, which would live on the same node as the row

The effect of the compound key means that those rows are effectively
treated as if they were part of the same column, making it a wide column.

Is that the right idea or do I have the row / rp thing wrong?

--f46d0444ecf3dde69304d15d2b58
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">







<p class=3D"">Trying to better grasp compound primary keys and what they ar=
e conceptually doing under the hood. When you create a table with a compoun=
d primary key in cql3 (<a href=3D"http://www.datastax.com/dev/blog/schema-i=
n-cassandra-1-1"><span class=3D"">http://www.datastax.com/dev/blog/schema-i=
n-cassandra-1-1</span></a>) the first part of the key is the partition key.=
 I get that and the subsequent parts help with the row name as I understand=
 it.</p>

<p class=3D"">So when you add a new row to that columnfamily/table, you are=
 still adding a row. In other words, the RandomPartitioner places it somewh=
ere in the cluster as a row on it&#39;s own as opposed to just adding a new=
 column to an existing row, which would live on the same node as the row</p=
>

<p class=3D"">The effect of the compound key means that those rows are effe=
ctively treated as if they were part of the same column, making it a wide c=
olumn.<br></p>
<p class=3D"">Is that the right idea or do I have the row / rp thing wrong?=
</p></div>

--f46d0444ecf3dde69304d15d2b58--