Какую версию ClickHouse использовать в производственной среде?
Прежде всего, давайте обсудим, почему люди задают этот вопрос. Существует две ключевые причины:
- ClickHouse разрабатывается с довольно высокой скоростью, и обычно в год выходит более 10 стабильных релизов. Это создает широкий выбор версий, и сделать выбор не так просто.
- Некоторые пользователи хотят избежать затрат времени на выяснение, какая версия лучше всего подходит для их случая, и просто следовать советам других.
Вторая причина более фундаментальна, поэтому начнем с неё, а затем вернемся к различным релизам ClickHouse.
Какую версию ClickHouse вы рекомендуете?
Соблазнительно нанять консультантов или довериться каким-то известным экспертам, чтобы избавиться от ответственности за вашу производственную среду. Вы устанавливаете какую-то конкретную версию ClickHouse, которую кто-то другой рекомендовал; если возникают проблемы с ней — это не ваша вина, а вина другого человека. Такое мышление — большая ловушка. Никто извне не знает лучше вас, что происходит в производственной среде вашей компании.
Так как же правильно выбрать, на какую версию ClickHouse обновляться? Или как выбрать вашу первую версию ClickHouse? Прежде всего, вам нужно инвестировать в создание реалистичной среды предрелиза. В идеальном мире это могла бы быть полностью идентичная теневое копирование, но это обычно дорого.
Вот несколько ключевых моментов для достижения разумной достоверности в среде предрелиза с невысокими затратами:
- Среда предрелиза должна выполнять набор запросов, максимально приближенный к тому, который вы собираетесь выполнять в производстве:
- Не делайте ее только для чтения с некоторыми замороженными данными.
- Не делайте ее только для записи, просто копируя данные без формирования каких-либо типичных отчетов.
- Не очищайте ее вместо применения миграций схемы.
- Используйте выборку реальных производственных данных и запросов. Постарайтесь выбрать такую выборку, которая все еще будет представительной и будет возвращать разумные результаты для запросов
SELECT
. Используйте обфускацию, если ваши данные чувствительны, и внутренние политики не позволяют им покидать производственную среду. - Убедитесь, что на среду предрелиза распространяется ваше программное обеспечение для мониторинга и оповещения так же, как и на вашу производственную среду.
- Если ваша производственная среда охватывает несколько центров обработки данных или регионов, убедитесь, что ваша среда предрелиза делает то же самое.
- Если в вашей производственной среде используются сложные функции, такие как репликация, распределенные таблицы и каскадные материализованные представления, убедитесь, что они настроены аналогично в среде предрелиза.
- Существует компромисс между использованием примерно такого же количества серверов или ВМ в среде предрелиза, как в производстве, но меньшего размера, или гораздо меньшего количества, но с тем же размером. Первый вариант может поймать дополнительные проблемы, связанные с сетью, в то время как второй проще в управлении.
Второй областью для инвестиций является инфраструктура автоматизированного тестирования. Не предполагайте, что если какой-то запрос выполнен успешно один раз, он будет продолжать работать вечно. Неплохо иметь некоторые юнит-тесты, в которых ClickHouse мокируется, но убедитесь, что ваш продукт имеет разумный набор автоматизированных тестов, которые выполняются против реального ClickHouse и проверяют, что все важные случаи использования продолжают работать как ожидалось.
Дополнительным шагом вперед может стать участие в этих автоматизированных тестах в инфраструктуре открытых тестов ClickHouse, которые постоянно используются в его повседневной разработке. Это определенно потребует дополнительных времени и усилий, чтобы узнать, как их запустить, а затем адаптировать ваши тесты к этой рамке, но это окупится, гарантируя, что релизы ClickHouse уже протестированы с их помощью, когда они объявляются стабильными, вместо того чтобы снова терять время на сообщение о проблеме после факта и затем ждать, пока исправление ошибок будет реализовано, обратно интегрировано и выпущено. Некоторые компании даже делают такие вкладки тестов в инфраструктуру как внутреннюю политику (это называется Правило Бейонсе в Google).
Когда у вас есть ваша среда предрелиза и инфраструктура тестирования, выбрать лучшую версию просто:
- Регулярно запускайте ваши автоматизированные тесты против новых релизов ClickHouse. Вы можете делать это даже для релизов ClickHouse, которые помечены как
testing
, но дальнейшее продвижение с ними не рекомендуется. - Разверните релиз ClickHouse, который прошел тесты, в предрелизную среду и проверьте, что все процессы работают как ожидалось.
- Сообщите о любых обнаруженных проблемах в ClickHouse GitHub Issues.
- Если не было серьезных проблем, должно быть безопасно начинать развертывание релиза ClickHouse в вашу производственную среду. Инвестиции в автоматизацию последовательного выпуска, которая реализует подход, подобный canary releases или green-blue deployments, могут еще больше снизить риск проблем в производстве.
Как вы могли заметить, в описанном подходе нет ничего специфического для ClickHouse - люди делают это для любой инфраструктуры, на которую они полагаются, если серьезно относятся к своей производственной среде.
Как выбрать между релизами ClickHouse?
Если вы заглянете в содержимое репозитория пакетов ClickHouse, вы увидите два типа пакетов:
stable
lts
(долгосрочная поддержка)
Вот некоторые рекомендации по выбору между ними:
stable
— это тип пакета, который мы рекомендуем по умолчанию. Они выпускаются примерно раз в месяц (и таким образом обеспечивают новые функции с разумной задержкой), и последние три стабильные версии поддерживаются в плане диагностики и обратно интеграции исправлений ошибок.lts
выходят дважды в год и поддерживаются в течение года после их первоначального выпуска. Вы можете предпочесть их по сравнению сstable
в следующих случаях:- Ваша компания имеет внутренние политики, которые не позволяют частые обновления или использование программного обеспечения без LTS.
- Вы используете ClickHouse в некоторых вторичных продуктах, которые либо не требуют никаких сложных функций ClickHouse, либо не имеют достаточно ресурсов, чтобы поддерживать его обновленным.
Многие команды, которые изначально думают, что lts
- это правильный путь, часто переходят на stable
, так как появляются недавние функции, которые важны для их продукта.
Еще одним моментом, о котором стоит помнить при обновлении ClickHouse: мы всегда следим за совместимостью между релизами, но иногда нецелесообразно ее сохранять, и некоторые мелкие детали могут измениться. Поэтому убедитесь, что вы проверили журнал изменений перед обновлением, чтобы увидеть, есть ли какие-либо примечания о несовместимых изменениях.