Чтобы повысить производительность чтения, я стараюсь иметь меньше базовых SSTable с LCS , поэтому я установил sstable_size_in_mb на 1280MB , как предлагалось в некоторых статьях, в которых указывалось из того, что значение по умолчанию 160MB было выбрано основной командой Cassandra давным-давно, на довольно старом сервере, имеющем только 2 ГБ ОЗУ. Однако мое беспокойство вызывает значение более высокого значения sstable_size_in_mb .
Что я понимаю, так это то, что LCS регулярно сжимает все sstables в L0 вместе со всеми sstables в L1, а затем заменяет все содержимое L1. Таким образом, каждый раз при замене L1 требования к аппаратному обеспечению ЦП / ОЗУ и усиление записи могут быть выше при более высоком значении sstable_size_in_mb . Действительно, если sstable_size_in_mb = 1280 МБ, то 10 таблиц по 1280 МБ в L1 необходимо объединять каждый раз со всеми таблицами L0. И может быть, это также имеет последствия для более высокого уровня, даже если заменяемые SSTables кажутся более низкими (одна SSTables L1 объединяется с 10 LSTables L2, тогда эти 10 SSTables L2 заменяются).
Вопросы:
Более высокое значение sstable_size_in_mb может повысить производительность чтения за счет уменьшения числа SSTable, включенных в таблицу CQL. Однако, каковы другие значения, чтобы иметь такое более высокое значение (например, 1280 МБ) для sstable_size_in_mb ?
Если более высокое значение, существует ли какая-либо соответствующая конфигурация для настройки (Garbadge Collector, кэш чанка и т. Д.), Чтобы обеспечить лучшую производительность для операций сжатия этих больших SSTables и с меньшей активностью GC?
Более субъективный вопрос: какое типичное значение sstable_size_in_mb вы используете в своем развертывании?