Какую версию ClickHouse использовать в продакшене?

Прежде всего разберёмся, почему вообще возникает этот вопрос. Есть две ключевые причины:

1. ClickHouse развивается с очень высокой скоростью, и обычно выходит более 10 стабильных релизов в год. В итоге доступен широкий спектр версий на выбор, и сделать этот выбор не так уж просто.
2. Некоторые пользователи не хотят тратить время на выяснение, какая версия лучше всего подходит для их сценария использования, и предпочитают просто следовать чьим-то рекомендациям.

Вторая причина более фундаментальна, поэтому начнём с неё, а затем вернёмся к разбору различных релизов ClickHouse.

Какую версию ClickHouse вы рекомендуете?

Соблазнительно нанять консультантов или довериться каким‑то известным экспертам, чтобы снять с себя ответственность за продуктивную среду. Вы устанавливаете какую‑то конкретную версию ClickHouse, которую кто‑то порекомендовал; если с ней возникнет проблема — это как будто уже не ваша вина, а чья‑то ещё. Такая логика — серьёзная ловушка. Ни один внешний специалист не знает лучше вас, что происходит в продуктивной среде вашей компании.

Как же правильно выбрать, на какую версию ClickHouse обновляться? Или как выбрать свою первую версию ClickHouse? Прежде всего, необходимо вложиться в создание реалистичной предпроизводственной среды. В идеале это могла бы быть полностью идентичная теневая копия продакшена, но обычно это дорого.

Ниже приведены некоторые ключевые моменты, которые позволяют добиться достаточного сходства с продакшеном в предпроизводственной среде без слишком высоких затрат:

• Предпроизводственная среда должна выполнять максимально близкий к продакшену набор запросов:
  • Не делайте её только для чтения с каким‑то «замороженным» набором данных.
  • Не делайте её только для записи, просто копируя данные без построения типовых отчётов.
  • Не очищайте её полностью вместо применения миграций схемы.
• Используйте выборку реальных продуктивных данных и запросов. Постарайтесь выбрать выборку, которая остаётся репрезентативной и позволяет SELECT‑запросам возвращать осмысленные результаты. Применяйте обфускацию, если данные чувствительные и внутренние политики не позволяют им покидать продуктивный контур.
• Убедитесь, что предпроизводственная среда покрыта вашей системой мониторинга и оповещений так же, как и продуктивная.
• Если ваш продакшен развёрнут в нескольких дата‑центрах или регионах, сделайте то же самое для предпроизводственной среды.
• Если в продакшене используются сложные функции, такие как репликация, распределённые таблицы и каскадные материализованные представления, убедитесь, что они аналогичным образом настроены и в предпроизводственной среде.
• Существует компромисс между использованием в предпроизводственной среде примерно такого же числа серверов или VM, как и в продакшене, но меньшего размера, и гораздо меньшего их количества, но того же размера. Первый вариант может помочь выявить дополнительные сетевые проблемы, а второй проще в управлении.

Вторая область, в которую нужно инвестировать, — это инфраструктура автоматизированного тестирования. Не думайте, что если какой‑то запрос однажды успешно выполнился, он будет успешно выполняться всегда. Допустимо иметь часть модульных тестов с мокированным ClickHouse, но убедитесь, что у вашего продукта есть разумный набор автоматизированных тестов, которые запускаются против реального ClickHouse и проверяют, что все важные сценарии по‑прежнему работают как ожидается.

Дополнительным шагом вперёд может стать вклад этих автоматизированных тестов в open-source инфраструктуру тестирования ClickHouse, которая постоянно используется в его повседневной разработке. Это, безусловно, потребует дополнительного времени и усилий, чтобы разобраться, как её запускать, а затем адаптировать свои тесты под этот фреймворк, но это окупится тем, что релизы ClickHouse будут уже протестированы на ваших тестах к моменту объявления их стабильными, вместо того чтобы снова и снова тратить время на сообщение о проблеме постфактум и ожидание реализации, бэкпорта и выпуска исправления. В некоторых компаниях вклад тестов в такую инфраструктуру при её использовании закреплён как внутренняя политика (в Google это называется правило Бейонсе).

Когда предпроизводственная среда и инфраструктура тестирования у вас есть, выбор лучшей версии становится простым:

1. Регулярно запускайте свои автоматизированные тесты против новых релизов ClickHouse. Это можно делать даже для релизов ClickHouse, помеченных как testing, но переходить к следующим шагам с ними не рекомендуется.
2. Разверните релиз ClickHouse, прошедший тесты, в предпроизводственной среде и убедитесь, что все процессы работают как ожидается.
3. Сообщайте обо всех обнаруженных проблемах в ClickHouse GitHub Issues.
4. Если серьёзных проблем не было, можно считать безопасным начать развертывание этого релиза ClickHouse в вашем продуктивном контуре. Инвестиции в автоматизацию постепенных релизов, реализующую подходы, похожие на canary releases или green-blue deployments, могут ещё больше снизить риск проблем в продакшене.

Как вы могли заметить, в описанном выше подходе нет ничего специфического для ClickHouse — так поступают с любыми инфраструктурными компонентами, на которые опираются, если относятся к своему продуктивному контуру серьёзно.

Как выбрать между релизами ClickHouse?

Если вы посмотрите содержимое репозитория пакетов ClickHouse, вы увидите два типа пакетов:

1. stable
2. lts (long-term support — долгосрочная поддержка)

Вот несколько рекомендаций, как выбирать между ними:

• stable — это тип пакета, который мы по умолчанию рекомендуем. Они выпускаются примерно раз в месяц (и, соответственно, с разумной задержкой добавляют новые возможности), а три последних стабильных релиза поддерживаются в части диагностики и обратного портирования исправлений ошибок.
• lts выпускаются два раза в год и поддерживаются в течение года после первого релиза. Вы можете предпочесть их вместо stable в следующих случаях:
  • В вашей компании есть внутренние политики, которые не допускают частые обновления или использование не-LTS‑ПО.
  • Вы используете ClickHouse во второстепенных продуктах, которым либо не требуются какие-либо сложные функции ClickHouse, либо у вас недостаточно ресурсов, чтобы поддерживать его в актуальном состоянии.

Многие команды, которые изначально считают, что lts — это правильный путь, в итоге всё равно переходят на stable из‑за какой‑то недавно появившейся функции, важной для их продукта.

Совет

Ещё один момент, который стоит учитывать при обновлении ClickHouse: мы всегда внимательно следим за совместимостью между релизами, но иногда сохранять её полностью нецелесообразно, и некоторые несущественные детали могут измениться. Поэтому перед обновлением обязательно просмотрите changelog, чтобы проверить, нет ли там заметок о несовместимых с предыдущими версиями изменениях.