Unfortunately, read immediately after write is another antipattern in
*all* eventually
consistent databases (though reading and writing both at quorum should
effectively produce immediate consistency).
The upcoming Change Data Capture feature that Michael Laing linked might be
a useful feature to
You could also follow this related issue:
https://issues.apache.org/jira/browse/CASSANDRA-8844
On Wed, May 25, 2016 at 12:04 PM, Aaditya Vadnere wrote:
> Thanks Eric and Mark, we were thinking along similar lines. But we already
> need Cassandra for regular database purpose, so instead of having
Thanks Eric and Mark, we were thinking along similar lines. But we already
need Cassandra for regular database purpose, so instead of having both
Kafka and Cassandra, the possibility of using Cassandra alone was explored.
Another usecase where update notification can be useful is when we want to
s
+1 to what Eric said, a queue is a classic C* anti-pattern. Something like
Kafka or RabbitMQ might fit your use case better.
Mark
On 24 May 2016 at 18:03, Eric Stevens wrote:
> It sounds like you're trying to build a queue in Cassandra, which is one
> of the classic anti-pattern use cases for
It sounds like you're trying to build a queue in Cassandra, which is one of
the classic anti-pattern use cases for Cassandra.
You may be able to do something clever with triggers, but I highly
recommend you look at purpose-built queuing software such as Kafka to solve
this instead.
On Tue, May 24
Hi experts,
We are evaluating Cassandra as messaging infrastructure for a project.
In our workflow Cassandra database will be synchronized across two nodes, a
component will INSERT/UPDATE records on one node and another component (who
has registered for the specific table) on second node will get
