typo: " If yes, it is considered a good practice for Cassandra" should read as " If yes, is it considered a good practice for Cassandra ?" ________________________________________ From: Rakesh Kumar <rakeshkumar...@outlook.com> Sent: Monday, February 27, 2017 10:06 To: 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. ________________________________________ 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 ?
