e that using
> Cassandra as a queuing table is anti pattern.
>
> From: Vincent Rischmann <m...@vrischmann.me>
> Sent: Friday, February 24, 2017 06:24
> To: user@cassandra.apache.org
> Subject: Which compaction strategy when modeling a dumb
user@cassandra.apache.org
Subject: Re: Which compaction strategy when modeling a dumb set
Do you update this table when an event is processed? If yes, it is considered
a good practice for Cassandra. I read somewhere that using Cassandra as a
queuing table is anti pattern.
___
ary 24, 2017 06:24
To: user@cassandra.apache.org
Subject: Which compaction strategy when modeling a dumb set
Hello,
I'm using a table like this:
CREATE TABLE myset (id uuid PRIMARY KEY)
which is basically a set I use for deduplication, id is a unique id for an
event, when I process the e
No I don't store events in Cassandra.
The real thing I'm doing is couting stuff: each event has a type, a user
associated with it, some other metadata. When I process an event I need
to increment those counters only if the event hasn't already been
processed. Our input event stream is Kafka and
Do you also store events in Cassandra? If yes, why not to add "processed" flag
to existing table(s), and fetch non-processed events with single SELECT?
Best regards, Vladimir Yudovin,
Winguzone - Cloud Cassandra Hosting
On Fri, 24 Feb 2017 06:24:09 -0500 Vincent Rischmann
Probably LCS although what you're implying (read before write) is an
anti-pattern in Cassandra. Something like this is a good indicator that you
should review your model.
Hello,
I'm using a table like this:
CREATE TABLE myset (id uuid PRIMARY KEY)
which is basically a set I use for deduplication, id is a unique id for
an event, when I process the event I insert the id, and before
processing I check if it has already been processed for deduplication.
