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

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

Заманчиво нанять консультантов или положиться на известных экспертов, чтобы снять с себя ответственность за продакшн-среду. Вы устанавливаете конкретную версию ClickHouse, которую порекомендовал кто-то другой; если с ней что-то пойдет не так, виноваты не вы, а кто-то еще. Такой подход к рассуждению — большая ловушка. Никто со стороны не знает лучше вас, что происходит в продакшн-среде вашей компании. Так как же правильно выбрать, до какой версии ClickHouse обновляться? И как выбрать первую версию ClickHouse? Прежде всего, нужно вложиться в настройку реалистичной предпроизводственной среды. В идеале это могла бы быть полностью идентичная теневая копия, но обычно это слишком дорого. Вот несколько ключевых моментов, которые помогут добиться разумного соответствия предпроизводственной среды при не слишком высоких затратах:
  • Предпроизводственная среда должна выполнять набор запросов, максимально близкий к тому, который вы планируете выполнять в продакшне:
    • Не делайте ее средой только для чтения с какими-то замороженными данными.
    • Не делайте ее средой только для записи, где данные просто копируются без построения типовых отчетов.
    • Не очищайте ее полностью вместо применения миграций схемы.
  • Используйте выборку реальных данных и запросов из продакшна. Постарайтесь подобрать такую выборку, которая останется репрезентативной и позволит запросам SELECT возвращать разумные результаты. Используйте обфускацию, если данные чувствительны и внутренние политики не позволяют выносить их за пределы продакшн-среды.
  • Убедитесь, что предпроизводственная среда так же охвачена вашими средствами мониторинга и оповещений, как и продакшн-среда.
  • Если ваша продакшн-среда охватывает несколько датацентров или регионов, предпроизводственная среда должна делать то же самое.
  • Если в продакшне используются сложные возможности, такие как репликация, distributed таблицы и каскадные materialized view, убедитесь, что в предпроизводственной среде они настроены аналогично.
  • Здесь есть компромисс: либо использовать в предпроизводственной среде примерно столько же серверов или VM, сколько в продакшне, но меньшего размера, либо гораздо меньше серверов или VM, но того же размера. Первый вариант может выявить дополнительные проблемы, связанные с сетью, а вторым проще управлять.
Вторая область, в которую стоит вложиться, — это инфраструктура автоматизированного тестирования. Не стоит считать, что если какой-то тип запроса однажды успешно выполнился, то так будет всегда. Вполне нормально иметь unit tests, где ClickHouse замокан, но убедитесь, что в вашем продукте есть разумный набор автоматизированных тестов, которые запускаются на реальном ClickHouse и проверяют, что все важные сценарии использования по-прежнему работают как ожидается. Дополнительным шагом вперед может стать добавление этих автоматизированных тестов в инфраструктуру тестирования ClickHouse с открытым исходным кодом, которая непрерывно используется в его повседневной разработке. Конечно, потребуется дополнительное время и усилия, чтобы разобраться, как ее запускать, а затем адаптировать ваши тесты под этот фреймворк, но это окупится: релизы ClickHouse уже будут проверены на них к моменту объявления их стабильными. Это лучше, чем снова и снова тратить время на сообщение о проблеме постфактум, а потом ждать, пока исправление будет реализовано, выполнен его бэкпорт и выпущен новый релиз. В некоторых компаниях даже есть внутренняя политика, предписывающая вносить такие тесты в инфраструктуру по мере ее использования (в Google это называется правилом Beyonce). Когда у вас уже есть предпроизводственная среда и инфраструктура тестирования, выбрать лучшую версию несложно:
  1. Регулярно запускайте автоматизированные тесты на новых релизах ClickHouse. Это можно делать даже для релизов ClickHouse, помеченных как testing, но переходить с ними к следующим шагам не рекомендуется.
  2. Разверните релиз ClickHouse, прошедший тесты, в предпроизводственной среде и проверьте, что все процессы работают как ожидается.
  3. Сообщайте обо всех обнаруженных проблемах в ClickHouse GitHub Issues.
  4. Если серьезных проблем не обнаружено, можно безопасно начинать развертывание релиза ClickHouse в продакшн-среде. Дополнительные вложения в автоматизацию постепенного выпуска, реализующую подход, похожий на канареечные релизы или green-blue deployments, могут еще сильнее снизить риск проблем в продакшне.
Как вы, возможно, заметили, в описанном выше подходе нет ничего специфичного для ClickHouse — так поступают с любым элементом инфраструктуры, от которого зависят, если серьезно относятся к своей продакшн-среде.

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

Если посмотреть содержимое репозитория пакетов ClickHouse, вы увидите два типа пакетов:
  1. stable
  2. lts (долгосрочная поддержка)
Ниже — несколько рекомендаций, которые помогут выбрать между ними:
  • stable — это тип пакетов, который мы рекомендуем по умолчанию. Они выходят примерно раз в месяц (поэтому новые возможности появляются без большой задержки), а три последних стабильных релиза поддерживаются в плане диагностики и бэкпорта исправлений ошибок.
  • lts выходят два раза в год и поддерживаются в течение года после первоначального релиза. Они могут быть предпочтительнее stable в следующих случаях:
    • В вашей компании действуют внутренние политики, которые не допускают частых обновлений или использования ПО, не относящегося к LTS.
    • Вы используете ClickHouse в каких-то второстепенных продуктах, где либо не нужны сложные возможности ClickHouse, либо не хватает ресурсов, чтобы поддерживать его в актуальном состоянии.
Многие команды, которые поначалу считают, что лучше выбрать lts, в итоге всё равно переходят на stable из-за какой-нибудь новой возможности, важной для их продукта.
Есть ещё один момент, о котором стоит помнить при обновлении ClickHouse: мы всегда внимательно следим за совместимостью между релизами, но в отдельных случаях сохранять её нецелесообразно, и какие-то мелкие детали могут меняться. Поэтому перед обновлением обязательно проверьте журнал изменений, чтобы узнать, нет ли там примечаний об обратно несовместимых изменениях.
Последнее изменение 10 июня 2026 г.