Какую версию 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: мы всегда следим за совместимостью между релизами, но иногда нецелесообразно ее сохранять, и некоторые мелкие детали могут измениться. Поэтому убедитесь, что вы проверили журнал изменений перед обновлением, чтобы увидеть, есть ли какие-либо примечания о несовместимых изменениях.