Using Cassandra as a Queue

Question

Using Cassandra as Queue:

Is it really that bad?

Setup: 5 node cluster, all operations execute at quorum

Using DateTieredCompaction should significantly reduce the cost of TombStones, and allow entire SSTables to be dropped at once.

• We add all messages to the queue with the same TTL
• We partition messages based on time (say 1 minute intervals), and keep track of the read-position.
• Messages consumed will be explicitly deleted. (only 1 thread extracts messages)
• Some Messages may be explicitly deleted prior to being read (i.e. we may have tombstones after the read-position). (i.e. the TTL initially used is an upper limit) gc_grace would probably be set to 0, as quorum reads will do blocking-repair (i.e. we can have repair turned off, as messages only reside in 1 cluster (DC), and all operations a quorum))
• Messages can be added/deleted only, no updates allowed.
• In our use case, if a tombstone does not replicate its not a big deal, its ok for us to see the same message multiple times occasionally. (Also we would likely not run Repair on regular basis, as all operations are executing at quorum.)

Thoughts?

Answer 1

Generally, it is an anti-pattern, this link talks much of the impact on tombstone: http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

My opinion is, try to avoid that if possible, but if you really understand the performance impact, and it is not an issue in your architecture, of course you could do that.

Another reason to not do that if possible is, the cassandra data structure is not designed for queues, it will always look ugly, UGLY!

Strongly suggest to consider Redis or RabbitMQ before making your final decision.