Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 75060 invoked from network); 7 May 2010 23:17:19 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 7 May 2010 23:17:19 -0000 Received: (qmail 99593 invoked by uid 500); 7 May 2010 23:17:18 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 99566 invoked by uid 500); 7 May 2010 23:17: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 99558 invoked by uid 99); 7 May 2010 23:17:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 May 2010 23:17:18 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rent.lupin.road@gmail.com designates 74.125.82.172 as permitted sender) Received: from [74.125.82.172] (HELO mail-wy0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 May 2010 23:17:13 +0000 Received: by wyb32 with SMTP id 32so1235185wyb.31 for ; Fri, 07 May 2010 16:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2M2L26c0LLFKH1hPy5pUZ5rMw9DgUtA3E4kuQG3CyBo=; b=Sc0FqTv2iWrwg7y/j3orMmEOo0XCO6kgFz+g62mdmHhYVKlpP8X0B3/Kbqhio7SjJZ /VG8uN6AfzOhs2afbfG6wBUcboT701oghOdbci2axZe6BnL3CLrxcGxFWltR1mhIKTJh 5xHoMnBg7T33zF8kKp+j6o8IzzMwra++1KbGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wht24OYfAJ7t/lwSbcO0gwIjdLkgixaIRxaMIIVVIyTMFnFSR/1l6xibP0L4+ohGoe SNnh6U4jKz3qwZgYVbHIV+uAaLPvYMGQo4e2XAvTz5LZSwgjPkkPXXqHWkVA9r0/YPjw /bV+mVJyPltRui0zekAqK4Faslqs/V/8UnNDY= MIME-Version: 1.0 Received: by 10.216.90.77 with SMTP id d55mr500826wef.17.1273274211674; Fri, 07 May 2010 16:16:51 -0700 (PDT) Received: by 10.216.50.15 with HTTP; Fri, 7 May 2010 16:16:51 -0700 (PDT) Date: Fri, 7 May 2010 19:16:51 -0400 Message-ID: Subject: Is multiget_slice performant when you're looking for lots of keys? From: James To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016e6d7ea6816aa8c048609416a --0016e6d7ea6816aa8c048609416a Content-Type: text/plain; charset=ISO-8859-1 Hi all, Apologies if I'm still stuck in RDBMS mentality - first project using Cassandra! I'll be using Cassandra to store quite a lot (10s of millions) of records, each of which has a type. I'll want to query the records to get all of a certain type; it's an analagous situation to the TaggedPosts schema from Arin's blog post ( http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model). The thing is, each type (or tag) row key will be pointing at millions of records. I know I can use multiget_slice with all those record IDs as one request, but is this The Right Way of "filtering" a large column family by type? Coming from an RDBMS-ingrained mindset, it seems kind of awkward... Thanks! James --0016e6d7ea6816aa8c048609416a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,
Apologies if I'm still stuck in RDBMS mentality - first pro= ject using Cassandra!

I'll be using Cassandra = to store quite a lot (10s of millions) of records, each of which has a type= .

I'll want to query the records to get all of a cert= ain type; it's an analagous situation to the TaggedPosts schema from Ar= in's blog post (http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-= model).

The thing is, each type (or tag) row key will be pointi= ng at millions of records. I know I can use multiget_slice with all those r= ecord IDs as one request, but is this The Right Way of "filtering"= ; a large column family by type?

Coming from an RDBMS-ingrained mindset, it seems kind o= f awkward...

Thanks!
James
--0016e6d7ea6816aa8c048609416a--