This is not a queue pattern and I'd recommend LCS for better read performance.
2017-02-27 16:06 GMT+01:00 Rakesh Kumar <rakeshkumar...@outlook.com>: > 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. > ________________________________________ > 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 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 event I insert the id, and before processing I > check if it has already been processed for deduplication. > > It works well enough, but I'm wondering which compaction strategy I should > use. I expect maybe 1% or less of events will end up duplicated (thus not > generating an insert), so the workload will probably be 50% writes 50% read. > > Is LCS a good strategy here or should I stick with STCS ? > -- Benjamin Roth Prokurist Jaumo GmbH · www.jaumo.com Wehrstraße 46 · 73035 Göppingen · Germany Phone +49 7161 304880-6 · Fax +49 7161 304880-1 AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
