Hello, I believe there is not a really specifically good strategy for counters. Often counter tables size is relatively low (compared to events / raw data). So depending on the workload you might want to pick one or the other. Given the high number of reads the table will have to face (during reads + writes), LCS might be a good choice if there is no better reason to pick another strategy. Be aware that LCS have the highest write amplification (Data will be written about 8 times on disk through compaction process) but should be in a very nice spot for reads, mostly touching one or a few SSTables.
In the past I did not care much about the compaction strategy for counters as I considered it to be negligible in my case (counters were MB big tables out of a few TB for the entire dataset). You can always pick a strategy you think would work better, and test the change on a canary node (use JMX to apply on 1 node only), see how it goes. I found the doc for this on Datastax website. I hope this will help: https://support.datastax.com/hc/en-us/articles/213370546-Change-CompactionStrategy-and-sub-properties-via-JMX C*heers, ----------------------- Alain Rodriguez - @arodream - al...@thelastpickle.com France / Spain The Last Pickle - Apache Cassandra Consulting http://www.thelastpickle.com 2018-01-17 16:14 GMT+00:00 Octavian Rinciog <octavian.rinc...@gmail.com>: > Hello! > I am using Cassandra 3.10. > I have a counter table, with the following schema and RF=1 > > CREATE TABLE edges ( > src_id text, > src_type text, > source text > weight counter, > PRIMARY KEY ((src_id, src_type), source) > ); > > SELECT vs UPDATE requests ratio for this table is 0.1 > READ vs WRITE rate, given by iostat is 100:1. > Counter cache hit rate is 80%, so only for 20% UPDATE requests, the > hard-disk is touched. > > I want to ask you which compation strategy is best for this table > (SizeTieredCompactionStrategy or > LeveledCompactionStrategy). > > Thank you, > -- > Octavian Rinciog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >