Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 57488 invoked from network); 2 Apr 2010 14:27:57 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Apr 2010 14:27:57 -0000 Received: (qmail 94458 invoked by uid 500); 2 Apr 2010 05:27:57 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 94359 invoked by uid 500); 2 Apr 2010 05:27:56 -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 94345 invoked by uid 99); 2 Apr 2010 05:27:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 05:27:56 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tsaloranta@gmail.com designates 74.125.83.172 as permitted sender) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 05:27:49 +0000 Received: by pvd12 with SMTP id 12so432277pvd.31 for ; Thu, 01 Apr 2010 22:27:29 -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 :date:received:message-id:subject:from:to:cc:content-type; bh=XdpC6GmiNoCLelTLBC5JGRi3unO+URXlw3uSbezTvQ0=; b=UhzEmsVhxx4L859P4RVM9GPIdGH1BPsvxs0gg62lZocMiPVyleTSS4xqgT9L4wqmp4 utd3Qw5qEfTm8lAWeuwcgkWClzgRcBBtSFb6Bzs3QLomCgYTmBLL2HFiqzy4n6S8cZa2 8wGX7PRB8oOfDxy+C6lERIVL0TGLDxcWxqL0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k3RTzpMa6kE0oZ+wnUDbTdG6ggTQtiHDxBfLD45o/ZlrfjK1RBP0L2o2ICoTjf4Pj3 +BQvKolEOG1ATpygAy50b2wxcR75RgojIQmnYtHd8h/HyBdyaDT0KXfQt+VwEMc+RbY6 nClZFN1u+04GJ+XSWZJWGqgNdgDGvs9MtqUe0= MIME-Version: 1.0 Received: by 10.140.226.1 with HTTP; Thu, 1 Apr 2010 22:27:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Apr 2010 22:27:29 -0700 Received: by 10.141.110.6 with SMTP id n6mr1292581rvm.163.1270186049323; Thu, 01 Apr 2010 22:27:29 -0700 (PDT) Message-ID: Subject: Re: Creating a Total Ordered Queue in Cassandra From: Tatu Saloranta To: user@cassandra.apache.org Cc: keith@raptr.com Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 1, 2010 at 9:43 PM, Jeremy Davis wrote: > > You are correct, it is not a queue in the classic sense... I'm storing the > entire "conversation" with a client in perpetuity, and then playing it back > in the order received. > > Rabbitmq/activemq etc all have about the same throughput 3-6K persistent > messages/sec, and are not good for storing the conversation forever... Also > I can easily scale cassandra past that message rate and not have to worry > about which message broker/cluster I'm connecting to/has the > conversation/etc. Also: I think RabbitMQ specifically does not have distributed message stores -- each message lives in just one queue node, meaning that when it is down (or gets wiped out), so are messages for that particular queue. Otherwise it seems like a really nice queuing system. The other potential concern is that all message metadata for it has to fit in central memory (message payload can be persisted I think) of the host that owns message. So while RabbitMQ and ActiveMQ are obviously better matches for queuing (with very powerful semantics, optional transactionality, etc. etc. etc.) Cassandra seems to have better distribution and fault-tolerance properties. This could be useful for some scenarios. In fact I wonder if "traditional" MQs could be considered quite a bit like RDBMSs regarding scalability, regarding distribution, horizontal scaling (or lack thereof) by adding nodes, and cost of ACID features (high expresive power vs simple scalability). I am actually also interested in similar aspects; using queue name and sequence identifier for implementing queue-like constructs, and was happy to see this question. But in my case, I would want to eventually also delete messages, so I would not have to rely as much on monotonically increasing ids aspect. This would allow many-senders-single-receiver use case, with little or no external synchronization. -+ Tatu +-