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

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

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

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

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

Есть соблазн нанять консультантов или довериться известным экспертам, чтобы избавиться от ответственности за вашу производственную среду. Вы устанавливаете какую-то конкретную версию ClickHouse, которую кто-то другой рекомендовал; если возникнет какая-то проблема с ней — это не ваша вина, а чья-то другая. Эта логика является большой ловушкой. Никто из внешних людей не знает лучше вас, что происходит в производственной среде вашей компании.

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

Вот несколько ключевых моментов, чтобы достичь разумной степени достоверности в пред-производственной среде с не слишком высокими затратами:

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

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

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

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

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

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

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

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

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

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

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

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

подсказка

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