Return-Path: 
 <user-return-8089-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org>
Delivered-To: apmail-cassandra-user-archive@www.apache.org
Received: (qmail 54389 invoked from network); 29 Jul 2010 21:39:37 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 29 Jul 2010 21:39:37 -0000
Received: (qmail 38523 invoked by uid 500); 29 Jul 2010 21:39:36 -0000
Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org
Received: (qmail 38472 invoked by uid 500); 29 Jul 2010 21:39:35 -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 38464 invoked by uid 99); 29 Jul 2010 21:39:35 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jul 2010 21:39:35 +0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of static.void.dev@gmail.com
 designates 209.85.210.44 as permitted sender)
Received: from [209.85.210.44] (HELO mail-pz0-f44.google.com) (209.85.210.44)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jul 2010 21:39:26 +0000
Received: by pzk6 with SMTP id 6so360598pzk.31
        for <user@cassandra.apache.org>; Thu, 29 Jul 2010 14:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from
         :user-agent:mime-version:to:subject:content-type
         :content-transfer-encoding;
        bh=SqZlVMEO9HrTZeF0rRvNGFfF5fa4lnGx2io9PJ7p+UM=;
        b=RlWPNhVG7gCjOsIOQhtrkynGTFMK4o59ZxkEL2ITVLuYeaEq2V6XbYDU1d9qCo5w+1
         zM2E/tUspGESWKcJqRNORuosYDtII7raz4V/hXMUCJj4OnmILStJZMesnqWWjyXYyB0f
         jG0V3gQoCu1TMzkNNGRadCvBnjE9sk8P3jgNM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject
         :content-type:content-transfer-encoding;
        b=scGHarF9k8Q9B0IKZOmwf0IIIszVe4OEHfsioYny8Baci4MSjWpLy1SZ3Qd6gpfrUu
         GZ/6Prczc5qDY9dCtgmIxFymqE4bcWFh8CCWcXhaGzlWxTTBkyRlDD5n3sJx9E+HTWmQ
         nSK5yPygQ+h9XAY9IFbGNx8Syq8vebqVeyuzA=
Received: by 10.114.127.17 with SMTP id z17mr1020550wac.158.1280439545237;
        Thu, 29 Jul 2010 14:39:05 -0700 (PDT)
Received: from Robert-Zotters-MacBook-Pro.local ([208.66.27.203])
        by mx.google.com with ESMTPS id g4sm2282750wae.2.2010.07.29.14.39.03
        (version=SSLv3 cipher=RC4-MD5);
        Thu, 29 Jul 2010 14:39:04 -0700 (PDT)
Message-ID: <4C51F4F7.6090801@gmail.com>
Date: Thu, 29 Jul 2010 14:39:03 -0700
From: Mark <static.void.dev@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Columns limit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Is there any limitations on the number of columns a row can have? Does 
all the day for a single key need to reside on a single host? If so, 
wouldn't that mean there is an implicit limit on the number of columns 
one can have... ie the disk size of that machine.

What is the proper way to handle timelines in this matter. For example 
lets say I wanted to store all user searches in a super column.

<ColumnFamily Name="SearchLogs"
                     ColumnType="Super"
                     CompareWith="TimeUUIDType"
                     CompareSubcolumnsWith="BytesType"/>

Which results in a structure as follows
{
    SearchLogs : {
        "foo" : {
             timeuuid_1 : { metadata goes here}
             timeuuid_2: { metadata goes here}
        },
        "bar" : {
             timeuuid_1 : { metadata goes here}
             timeuuid_2: { metadata goes here}
        }
   }
}

Couldn't this theoretically run out of columns for the same search term 
because for each unique term there can (and will) be many timeuuid columns?

Thanks for clearing this up for me.