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
>
>

Reply via email to