Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 60945 invoked from network); 7 Oct 2009 21:45:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 7 Oct 2009 21:45:22 -0000 Received: (qmail 21415 invoked by uid 500); 7 Oct 2009 21:45:21 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 21373 invoked by uid 500); 7 Oct 2009 21:45:21 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 21364 invoked by uid 99); 7 Oct 2009 21:45:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Oct 2009 21:45:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ikatkov@gmail.com designates 209.85.220.209 as permitted sender) Received: from [209.85.220.209] (HELO mail-fx0-f209.google.com) (209.85.220.209) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Oct 2009 21:45:10 +0000 Received: by fxm5 with SMTP id 5so4832884fxm.27 for ; Wed, 07 Oct 2009 14:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=c3KTT9h+fuHLmyzXw8kBSf3jmEXhA7ltgfgc4sWT2po=; b=NZVaa2deqxUkhEioCyDEiN+xDqWVLt5zwDkDgYscHQse0d2W4iZYsN6o3cFjqW1itU HUiiUJ1XZlkEsECBzRJzo/SMPavxbyGxVVLD5WB8fQTbnpgUgRlo/noPaySmrI8W/0GI hOANEB26x0xHE/bsHZ1N4jE1F1JLhjqsGVAJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=xS/zsmJn7CJE43ST9D5wMIJQrhN3deUhNWEuBma3JPMn98Oqgs+sFpy/XjPwg6CqMB crBrd9h+a9o1T17BPTzo7OaF+MG/SnV9/RMmJY1PIKlNjG9e861mJBllG85qXC95FeuO 9G5LnEhA6H2NQ+5kWZdE0AbbnZdy11wUYPTZ8= MIME-Version: 1.0 Received: by 10.223.1.137 with SMTP id 9mr134580faf.93.1254951890118; Wed, 07 Oct 2009 14:44:50 -0700 (PDT) In-Reply-To: References: <23b1e84e0910071418h1f7ae083n38064b4e890af6d0@mail.gmail.com> From: Igor Katkov Date: Wed, 7 Oct 2009 17:44:30 -0400 Message-ID: <23b1e84e0910071444k14419ee6rba02c9af5e42add1@mail.gmail.com> Subject: Re: circular buffer To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=0015174764da9ee90004755f414a X-Virus-Checked: Checked by ClamAV on apache.org --0015174764da9ee90004755f414a Content-Type: text/plain; charset=ISO-8859-1 Are there any hooks (API), for instance I could implement a simmilar RowMutationVerbHandler: IVerbHandler that would do the purging on the server side? On Wed, Oct 7, 2009 at 5:32 PM, Jonathan Ellis wrote: > It's not a fantastic fit because as you say you need to read the > contents to be able to see which if any need to be deleted. (On the > bright side if you are sorting by time uuid, for instance, you won't > need an extra sort step.) > > I would predict it would perform better than doing the same thing in a > SQL database though. > > -Jonathan > > On Wed, Oct 7, 2009 at 4:18 PM, Igor Katkov wrote: > > Hi, > > > > I was wondering if it's a good idea to use Cassandra for persist-able > > circular buffer? > > http://en.wikipedia.org/wiki/Circular_buffer > > > > The goal is to have at most X columns per key, where new columns wipe old > > columns out. > > There will be much more writes than reads. What bothers me is how to > handle > > "old" columns. > > I understand that there there is no multi-remove, but even if there was > that > > would not help much. > > > > Perhaps Cassandra is ill-suited for the task... What'd you recommend? > > > > It could be done in SQL one way or another but it would be pretty as > well: > > 1. always insert and purge once in a while - this approach fails under > any > > significant load > > 2. purge on insert - still requires unnecessary reads > > > --0015174764da9ee90004755f414a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are there any hooks (API), for instance I could implement a simmilar RowMut= ationVerbHandler: IVerbHandler that would do the purging on the server side= ?

On Wed, Oct 7, 2009 at 5:32 PM, Jonatha= n Ellis <jbellis@= gmail.com> wrote:
It's not a fa= ntastic fit because as you say you need to read the
contents to be able to see which if any need to be deleted. =A0(On the
bright side if you are sorting by time uuid, for instance, you won't need an extra sort step.)

I would predict it would perform better than doing the same thing in a
SQL database though.

-Jonathan

On Wed, Oct 7, 2009 at 4:18 PM, Igor Katkov <ikatkov@gmail.com> wrote:
> Hi,
>
> I was wondering if it's a good idea to use Cassandra for persist-a= ble
> circular buffer?
> http://en.wikipedia.org/wiki/Circular_buffer
>
> The goal is to have at most X columns per key, where new columns wipe = old
> columns out.
> There will be much more writes than reads. What bothers me is how to h= andle
> "old" columns.
> I understand that there there is no multi-remove, but even if there wa= s that
> would not help much.
>
> Perhaps Cassandra is ill-suited for the task... What'd you recomme= nd?
>
> It could be done in SQL one way or another but it would be pretty as w= ell:
> 1. always insert and purge once in a while - this approach fails under= any
> significant load
> 2. purge on insert - still requires unnecessary reads
>

--0015174764da9ee90004755f414a--