Кассандра: обслуживание

Я неопытен в Cassandra, но у меня есть некоторый опыт работы с реляционными базами данных на основе SQL.

Мне не удалось найти информацию о передовых методах поддержки Cassandra после развертывания. Нужно ли VACUUM базы данных? Я должен думать, что загрузка чтения / записи вызывает фрагментацию в хранилище.

Или в более общем плане: каковы наилучшие практики для поддержки развертывания Cassandra? Что нужно делать через регулярные промежутки времени, чтобы поддерживать работоспособность системы? Руководство по эксплуатации действительно не обсуждает этот аспект.

Спасибо.

В общем, хорошо спроектированный кластер может прожить ГОДЫ без прикосновения. У меня были кластеры, которые работали годами. Однако вот несколько рекомендаций:

Мониторинг чрезвычайно важен:

1) Мониторинг задержек. Используйте opscenter или ваши любимые инструменты метрик, чтобы отслеживать задержки. Увеличение задержек может быть признаком возникновения проблем, включая паузы GC (чаще встречающиеся в рабочих нагрузках чтения, чем в рабочих нагрузках записи), проблемы sstable и тому подобное.

2) Монитор sstable подсчитывает. Количество SSTable увеличится, если вы превысите сжатие (каждый sstable записывается ровно один раз - удаление обрабатывается путем объединения старых sstable в новые sstable посредством сжатия).

3) Отслеживать изменения состояния узла (вверх / вниз и т. Д.). Если вы видите колебание узлов, исследуйте, так как это ненормально.

4) Следите за использованием вашего диска - традиционно вам нужно оставаться ниже 50% (особенно если вы используете сжатие STCS).

Есть некоторые основные вещи, которые вы должны и не должны делать регулярно:

1) Не запускайте явно nodetool compact. Вы упоминаете, что сделали это, это не смертельно, но оно создает очень большие sstables, которые с меньшей вероятностью будут участвовать в уплотнении в будущем. Вам не обязательно продолжать его запускать, но иногда это может помочь избавиться от удаленных / перезаписанных данных.

2) nodetool repairобычно рекомендуется каждые gc_grace_seconds(по умолчанию 10 дней). Существуют рабочие нагрузки, в которых это менее важно - главная причина, по которой вам НЕОБХОДИМО восстановить, - это убедиться, что маркеры удаления ( tombstones) переданы до истечения срока их действия (они действуют gc_grace_seconds, если узел не работает, когда произошло удаление, эти данные могут вернуться к жизни. без ремонта!). Если вы не производите удаления и запрашиваете с достаточным уровнем согласованности (например, читает и пишет в QUORUM), вы можете фактически прожить жизнь без ремонта.

3) Если вы собираетесь ремонтировать, подумайте об использовании пошагового ремонта и ремонтируйте небольшие диапазоны за раз.

4) Стратегии уплотнения имеют значение - много. STCS отлично подходит для записи, LCS отлично подходит для чтения. DTCS имеет некоторые причуды.

5) Модели данных имеют значение - точно так же, как среды RDBMS / SQL сталкиваются с проблемами, когда неиндексированные запросы попадают в большие таблицы, Cassandra может создавать проблемы с очень большими строками / разделами.

6) Снимки дешевы. Очень дешевый. Почти мгновенные, просто жесткие ссылки, они почти сразу не стоят дискового пространства. Используйте снимок перед обновлением версий, особенно основных версий.

7) Будьте осторожны с удалениями. Как указано в # 2, удаление создает больше данных на диске и не освобождает их по крайней мере gc_grace_seconds.

Когда все остальное терпит неудачу:

Я видел статьи, в которых говорится, что Cassandra in prod требует отдельного руководителя для управления кластером любого размера - я не знаю, что это обязательно так, но если вы обеспокоены, вы можете нанять стороннего консультанта (TheLastPickle, Pythian ) или иметь контракт на поддержку (Datastax), чтобы обеспечить вам спокойствие.

Согласно ремонтной документации Cassandra , nodetool repairследует запускать в следующих ситуациях:

• В качестве лучшей практики, вы должны планировать ремонт еженедельно. Примечание. Если удаление никогда не происходит, вам все равно следует запланировать регулярный ремонт. Имейте в виду, что установка нулевого столбца является удалением.
• Во время восстановления узла. Например, при возвращении узла в кластер после сбоя.
• На узлах, содержащих данные, которые не часто читаются.
• Чтобы обновить данные на узле, который был недоступен.

Я должен думать, что загрузка чтения / записи вызывает фрагментацию в хранилище.

Данные в Кассандре не «фрагментируются» так, как вы думаете. Однако удаление действительно запускает размещение надгробий, а обычный компактный процесс удаляет надгробия.

Теперь я понимаю, что уплотнение имеет большое значение и выполняется автоматически

Правильный. Представитель DataStax сказал мне, что после запуска compactвручную вам всегда придется запускать его вручную. Причина в том, что сжатие работает путем «сжатия» всех существующих SSTABLES в пространстве ключей в один файл SSTABLE. В этом файле SSTABLE могут быть небольшие семейства столбцов, размер которых будет превышать порог сжатия, и потребуется слишком много времени, чтобы вероятность повторного запуска автоматического сжатия очень мала.

По сути, не забудьте запланировать регулярное nodetool repair, никогда не запускать nodetool compactи реализовать стратегию резервного копирования (моментальные снимки, инкрементные резервные копии или оба).