Нужна ли Cassandra Autocompaction для полностью неизменных данных?

Question

Я пытаюсь оптимизировать производительность имеющейся у нас таблицы Кассандры, которая представляет собой классические c данные о событиях с временными метками. Проходя через различные настройки, я потратил некоторое время на изучение стратегий уплотнения и на то, как это происходит в Кассандре.

Сначала я подумал, что TimeWindowCompaction идеально подходит для нашего варианта использования, но потом я понял, что мы никогда не удаляем и не обновляем Данные.

Возможно ли, что лучше полностью отключить сжатие? Как формируются SSTables, когда вообще нет стратегии уплотнения?

Answer 1

SSTables записываются на диск, когда в памяти (memtables) заполняется или сбрасывается. Если вы отключите сжатие для таблицы, у вас будет много очень маленьких SSTable. Независимо от того, собираетесь ли вы обновлять или удалять данные, вам нужно сжать данные в том виде, в котором они написаны.

Какая стратегия сжатия вы будете использовать, зависит от ваших требований к доступу. Этот является хорошим базовым c руководством по выбору стратегии уплотнения, а this - более подробным руководством по уплотнению в Кассандре.

Answer 2

Как уже упоминалось, при записи происходит сброс памяти на диск при определенных условиях. Каждый раз, когда это происходит, вы получаете sstable. Со временем, по мере продолжения изменений, у вас будет несколько таблиц sstable, составляющих вашу таблицу на этом узле. Предполагая, что у вас есть несколько sstables для таблицы, у вас может быть «строка», которая находится в нескольких sstable, и когда для этой строки происходит чтение, Cassandra должна будет прочитать все sstables для этой строки, объединить результаты, а затем отвечать. Это замедляет чтение. Помните, Cassandra высоко оптимизирована для записи, чтение платит цену. Уплотнение также используется, как вы упомянули, для очистки надгробного камня / удаления.

Вы сами решаете, как происходит уплотнение. По умолчанию используется стратегия многоуровневого уплотнения (STCS). Алгоритм этой стратегии состоит в том, что когда X sstables имеют одинаковый размер, они уплотняются вместе в новый sstable (и старые sstables отбрасываются). Если результат нового sstable больше (например, 4 sstables сжаты в 1, и все строки уникальны), может пройти много времени, прежде чем он снова сможет участвовать в уплотнении (из-за необходимости X из них того же размера квалифицироваться). Имеет ли это смысл?

К вашему мнению, "почему бы просто не иметь один sstable". Для чтения оптимальным является один "упакованный" sstable. Однако со временем у вас будут появляться новые sstables по мере возникновения изменений (sstables всегда будут генерироваться для новых изменений - вы не можете это остановить), и ваш один большой sstable, как упоминалось ранее, может не иметь права на очистку, в результате чего производительность снова ухудшается. Это STCS.

Существуют и другие стратегии, каждая из которых оптимизирована для определенных условий. Идея состоит в том, чтобы держать вещи как можно более чистыми, не перегружая систему непрерывным сжатием данных - таким образом, различные подходы / стратегии на выбор. Каждый из них имеет свои преимущества и недостатки для других.

Еще одна вещь, которую следует помнить, это то, что чтение происходит на уровне раздела. Если у вас была таблица, в которой ключом раздела был первичный ключ, и каждая строка была вставлена ​​без удалений, ttls или чего-либо еще в этом роде, то вы правы, сжатие для таблицы такого типа вообще не понадобится. Вы можете иметь 1 миллион sstables, и это не будет иметь значения. Однако, если у вас есть первичный ключ, в котором ключ раздела является частью, но не всем, это может повлиять на производительность чтения (чтения происходят на уровне раздела, и у вас будет несколько строк и sstables для каждого раздела). В этом сценарии вам может не потребоваться сжатие для очистки (опять-таки при условии, что только вставки, без ttls / deletes и т. Д. c), но чем больше sstables для одного раздела, тем медленнее может быть чтение (в зависимости от того, сколько sstables каждый постоянный раздел и использование некоторых встроенных оптимизаций, которые отфильтровывают sstables для разделов).

Надеюсь, это поможет.

Answer 3

Отключение сжатия не является хорошим вариантом, но вы можете изменить стратегию сжатия в зависимости от поведения вашего приложения. В вашем случае вы можете go с помощью стратегии многоуровневого сжатия размера или стратегии выравнивания с выравниванием.

Однако TimeWindowCompactionStrategy хороший вариант для данных временных рядов. Вы можете ссылаться на детали, как показано ниже, чтобы понять варианты использования.

TimeWindowCompactionStrategy (TWCS) разработан специально для рабочих нагрузок, где полезно иметь данные на диске, сгруппированные по временной метке данных, что является общей целью, когда рабочая нагрузка имеет временные ряды по своей природе или когда все данные записываются с использованием TTL. В рабочей нагрузке с истекающим сроком действия / TTL содержимое всего SSTable, вероятно, истекает примерно в одно и то же время, что позволяет полностью отбросить его.

http://cassandra.apache.org/doc/latest/operating/compaction.html