cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatu Saloranta <>
Subject Re: Creating a Total Ordered Queue in Cassandra
Date Fri, 02 Apr 2010 05:27:29 GMT
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

-+ Tatu +-

View raw message