Return-Path: 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 59FBFD07F for ; Sat, 22 Dec 2012 12:41:24 +0000 (UTC) Received: (qmail 17520 invoked by uid 500); 22 Dec 2012 12:41:21 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 17038 invoked by uid 500); 22 Dec 2012 12:41:15 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 17010 invoked by uid 99); 22 Dec 2012 12:41:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Dec 2012 12:41:14 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of boneill42@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vc0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Dec 2012 12:41:10 +0000 Received: by mail-vc0-f180.google.com with SMTP id p16so6154226vcq.11 for ; Sat, 22 Dec 2012 04:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=OFrnQbzgDFnInyIX19vKMLlKu00bTIdg1SlzrPAU5t8=; b=0wGTTYjxpcD1OZ0T56mKZ3jmYKaZkuPSRFVPMdbdXZ2vXuS1lqKcfOZXFHk98ypEdj eR9C4gQhkrQBUe7EE/WUj58WPS5qM8RDhrfGUOEgwIb76TQxcFe/t/30UE5IVtgLFKfD 5Pw/U+DXA7vCbq2q+YW+xG4IEmCFHnfi4X7H4FJTXmHhrMmgw5TGYz8GpfeOxS/VkgxN ZhqWrp4wFnwaBeNwsKDUsMkcE05bdo3R6sTmkckfH9AytGwsVsw3eidJXaJXSVU9+2ft 40FPRiOH53A/jvXI9uvjx1F0l9RnrRdEDDJ2tW5ByDOxcWNcv3zicvXakEiRCdz2udvr 2Nnw== X-Received: by 10.58.222.40 with SMTP id qj8mr25234774vec.36.1356180049747; Sat, 22 Dec 2012 04:40:49 -0800 (PST) Received: from [192.168.0.100] (c-68-63-149-124.hsd1.pa.comcast.net. [68.63.149.124]) by mx.google.com with ESMTPS id dl18sm12318729vdb.2.2012.12.22.04.40.45 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Dec 2012 04:40:47 -0800 (PST) Sender: "Brian O'Neill" From: Brian O'Neill Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-8--84405158 Subject: Re: CQL3 Compound Primary Keys - Do I have the right idea? Date: Sat, 22 Dec 2012 07:38:36 -0500 In-Reply-To: To: user@cassandra.apache.org References: Message-Id: X-Mailer: Apple Mail (2.1085) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-8--84405158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agreed. I actually flip between cli and cqlsh these days.=20 cqlsh shows the logical view. cli shows the physical view. This is useful, especially when developing using a thrift-based client. Here are the slides and video if you want to have a look. -brian On Dec 22, 2012, at 3:36 AM, Wz1975 wrote: > You still add one row. The column name is the remaining part of the = composite key (repeat for each column) plus each of the column which is = not in the composite key. I found it is much clearer to look at the data = through Cassandra -cli which shows you how data is stored.=20 >=20 >=20 > Thanks. > -Wei >=20 > Sent from my Samsung smartphone on AT&T=20 >=20 >=20 > -------- Original message -------- > Subject: CQL3 Compound Primary Keys - Do I have the right idea?=20 > From: Adam Venturella =20 > To: user@cassandra.apache.org=20 > CC:=20 >=20 >=20 > 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. >=20 > 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 >=20 > 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. >=20 > Is that the right idea or do I have the row / rp thing wrong? >=20 Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/ --Apple-Mail-8--84405158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Here = are the slides<= span class=3D"Apple-style-span" style=3D"color: rgb(67, 67, 67); = font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: = 16px; "> and video&nbs= p;if you want to have a = look.

-brian


=

On Dec 22, 2012, at 3:36 AM, Wz1975 wrote:

You still add one row. The  column name is = the remaining part of the composite key (repeat for each column) plus = each of the column which is not in the composite key. I found it is much = clearer to look at the data through Cassandra -cli which shows you how = data is stored. 


Thanks.
-Wei

Sent from my Samsung = smartphone on AT&T



-------- Original message = --------
Subject: CQL3 Compound Primary Keys - Do I have the right = idea?
From: Adam Venturella <aventurella@gmail.com> =
To: user@cassandra.apache.org =
CC:


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?

=


Brian ONeill
Lead = Architect, Health Market Science (http://healthmarketscience.com
mobile:215.588.6024blog: http://weblogs.java.net/blog/boneill42/blog: http://brianoneill.blogspot.com/

= --Apple-Mail-8--84405158--