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