Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 69104 invoked from network); 8 Feb 2011 19:22:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Feb 2011 19:22:23 -0000 Received: (qmail 83803 invoked by uid 500); 8 Feb 2011 19:22:21 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 83448 invoked by uid 500); 8 Feb 2011 19:22:18 -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 83431 invoked by uid 99); 8 Feb 2011 19:22:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Feb 2011 19:22:17 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Feb 2011 19:22:09 +0000 Received: by pvc21 with SMTP id 21so1483631pvc.31 for ; Tue, 08 Feb 2011 11:21:47 -0800 (PST) Received: by 10.142.245.20 with SMTP id s20mr14906877wfh.225.1297192906874; Tue, 08 Feb 2011 11:21:46 -0800 (PST) Received: from Ben-Coverstons-MacBook-Pro.local (c-67-166-71-138.hsd1.ut.comcast.net [67.166.71.138]) by mx.google.com with ESMTPS id b11sm7982487wff.9.2011.02.08.11.21.45 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 11:21:46 -0800 (PST) Message-ID: <4D5197C7.20108@datastax.com> Date: Tue, 08 Feb 2011 12:21:43 -0700 From: Benjamin Coverston User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Subcolumn Indexing References: <415F86341B2D7B4480FAE34D76D00DB2010D87DBED@NYKPCMMGMB07.INTRANET.BARCAPINT.COM> In-Reply-To: <415F86341B2D7B4480FAE34D76D00DB2010D87DBED@NYKPCMMGMB07.INTRANET.BARCAPINT.COM> Content-Type: multipart/alternative; boundary="------------020304000907010409020306" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------020304000907010409020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Does this just mean the exhaustive list of the column names not all > the values? > No, this means the entire supercolumn, names and values. When the client tries to access any subcolumn in the supercolumn it has to read the entire supercolumn. > > So if I have a super column that has a map of keys that only contain > two columns max each this shouldn't really be a performance concern > correct? This becomes an issue when you have lots of subcolumns if I'm > reading this correctly? I'm looking at using the super column as a > good way to cluster data, say I was storing home addresses I might use > the zipcode as the super column if I cared mostly about accessing data > by logical area for instance. Thanks for the help. > That is one way to logically group the values, but I think that a simpler solution may be to store the home address as a single row in a column family, then use a dynamic column family to store references to those addresses per zip code. > jt > > _______________________________________________ > > This e-mail may contain information that is confidential, privileged > or otherwise protected from disclosure. If you are not an intended > recipient of this e-mail, do not duplicate or redistribute it by any > means. Please delete it and any attachments and notify the sender that > you have received it in error. Unless specifically indicated, this > e-mail is not an offer to buy or sell or a solicitation to buy or sell > any securities, investment products or other financial product or > service, an official confirmation of any transaction, or an official > statement of Barclays. Any views or opinions presented are solely > those of the author and do not necessarily represent those of > Barclays. This e-mail is subject to terms available at the following > link: www.barcap.com/emaildisclaimer > . By messaging with Barclays > you consent to the foregoing.Barclays Capital is the investment > banking division of Barclays Bank PLC, a company registered in England > (number 1026167) with its registered office at 1 Churchill Place, > London, E14 5HP.This email may relate to or be sent from other members > of the Barclays Group.// > > _______________________________________________ > --------------020304000907010409020306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Does this just mean the exhaustive list of the column names not all the values?

No, this means the entire supercolumn, names and values. When the client tries to access any subcolumn in the supercolumn it has to read the entire supercolumn.

So if I have a super column that has a map of keys that only contain two columns max each this shouldn’t really be a performance concern correct? This becomes an issue when you have lots of subcolumns if I’m reading this correctly? I’m looking at using the super column as a good way to cluster data, say I was storing home addresses I might use the zipcode as the super column if I cared mostly about accessing data by logical area for instance. Thanks for the help.

That is one way to logically group the values, but I think that a simpler solution may be to store the home address as a single row in a column family, then use a dynamic column family to store references to those addresses per zip code.

 

jt

_______________________________________________

 

This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing.  Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be sent from other members of the Barclays Group.

_______________________________________________

--------------020304000907010409020306--