Какую версию 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 в вашу производственную среду. Инвестирование в автоматизацию поэтапного развертывания, которая реализует подход, аналогичный canary releases или green-blue deployments, может еще больше снизить риск проблем в производстве.

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

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

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

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

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

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

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

подсказка

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