Stephane, As everything good, LCS comes at certain price.
LCS will put most load on you I/O system (if you use spindles - you may need to be careful about that) and on CPU. Also LCS (by default) may fall back to STCS if it is falling behind (which is very possible with heavy writing activity) and this will result in higher disk space usage. Also LCS has certain limitation I have discovered lately. Sometimes LCS may not be able to use all your node's resources (algorithm limitations) and this reduces the overall compaction throughput. This may happen if you have a large column family with lots of data per node. STCS won't have this limitation. By the way, the primary goal of LCS is to reduce the number of sstables C* has to look at to find your data. With LCS properly functioning this number will be most likely between something like 1 and 3 for most of the reads. But if you do few reads and not concerned about the latency today, most likely LCS may only save you some disk space. On Sat, Nov 22, 2014 at 6:25 PM, Stephane Legay <sle...@looplogic.com> wrote: > Hi there, > > use case: > > - Heavy write app, few reads. > - Lots of updates of rows / columns. > - Current performance is fine, for both writes and reads.. > - Currently using SizedCompactionStrategy > > We're trying to limit the amount of storage used during compaction. Should > we switch to LeveledCompactionStrategy? > > Thanks > -- Nikolai Grigoriev (514) 772-5178
