> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Какую версию ClickHouse использовать в продакшне?
> На этой странице приведены рекомендации о том, какую версию ClickHouse использовать в продакшне
Прежде всего, давайте разберемся, почему вообще возникает этот вопрос. На это есть две ключевые причины:
1. ClickHouse развивается довольно быстро, и обычно за год выходит более 10 стабильных релизов. Из-за этого выбор получается очень широким, и принять решение не так уж просто.
2. Некоторые пользователи не хотят тратить время на выяснение того, какая версия лучше всего подходит для их сценария, и предпочитают просто следовать чужой рекомендации.
Вторая причина более фундаментальна, поэтому начнем с нее, а затем вернемся к тому, как ориентироваться среди различных релизов ClickHouse.
## Какую версию ClickHouse вы рекомендуете?
Заманчиво нанять консультантов или положиться на известных экспертов, чтобы снять с себя ответственность за продакшн-среду. Вы устанавливаете конкретную версию ClickHouse, которую порекомендовал кто-то другой; если с ней что-то пойдет не так, виноваты не вы, а кто-то еще. Такой подход к рассуждению — большая ловушка. Никто со стороны не знает лучше вас, что происходит в продакшн-среде вашей компании.
Так как же правильно выбрать, до какой версии ClickHouse обновляться? И как выбрать первую версию ClickHouse? Прежде всего, нужно вложиться в настройку **реалистичной предпроизводственной среды**. В идеале это могла бы быть полностью идентичная теневая копия, но обычно это слишком дорого.
Вот несколько ключевых моментов, которые помогут добиться разумного соответствия предпроизводственной среды при не слишком высоких затратах:
* Предпроизводственная среда должна выполнять набор запросов, максимально близкий к тому, который вы планируете выполнять в продакшне:
* Не делайте ее средой только для чтения с какими-то замороженными данными.
* Не делайте ее средой только для записи, где данные просто копируются без построения типовых отчетов.
* Не очищайте ее полностью вместо применения миграций схемы.
* Используйте выборку реальных данных и запросов из продакшна. Постарайтесь подобрать такую выборку, которая останется репрезентативной и позволит запросам `SELECT` возвращать разумные результаты. Используйте обфускацию, если данные чувствительны и внутренние политики не позволяют выносить их за пределы продакшн-среды.
* Убедитесь, что предпроизводственная среда так же охвачена вашими средствами мониторинга и оповещений, как и продакшн-среда.
* Если ваша продакшн-среда охватывает несколько датацентров или регионов, предпроизводственная среда должна делать то же самое.
* Если в продакшне используются сложные возможности, такие как репликация, distributed таблицы и каскадные materialized view, убедитесь, что в предпроизводственной среде они настроены аналогично.
* Здесь есть компромисс: либо использовать в предпроизводственной среде примерно столько же серверов или VM, сколько в продакшне, но меньшего размера, либо гораздо меньше серверов или VM, но того же размера. Первый вариант может выявить дополнительные проблемы, связанные с сетью, а вторым проще управлять.
Вторая область, в которую стоит вложиться, — это **инфраструктура автоматизированного тестирования**. Не стоит считать, что если какой-то тип запроса однажды успешно выполнился, то так будет всегда. Вполне нормально иметь unit tests, где ClickHouse замокан, но убедитесь, что в вашем продукте есть разумный набор автоматизированных тестов, которые запускаются на реальном ClickHouse и проверяют, что все важные сценарии использования по-прежнему работают как ожидается.
Дополнительным шагом вперед может стать добавление этих автоматизированных тестов в [инфраструктуру тестирования ClickHouse с открытым исходным кодом](https://github.com/ClickHouse/ClickHouse/tree/master/tests), которая непрерывно используется в его повседневной разработке. Конечно, потребуется дополнительное время и усилия, чтобы разобраться, [как ее запускать](/ru/resources/develop-contribute/contribute/tests), а затем адаптировать ваши тесты под этот фреймворк, но это окупится: релизы ClickHouse уже будут проверены на них к моменту объявления их стабильными. Это лучше, чем снова и снова тратить время на сообщение о проблеме постфактум, а потом ждать, пока исправление будет реализовано, выполнен его бэкпорт и выпущен новый релиз. В некоторых компаниях даже есть внутренняя политика, предписывающая вносить такие тесты в инфраструктуру по мере ее использования (в Google это называется [правилом Beyonce](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well)).
Когда у вас уже есть предпроизводственная среда и инфраструктура тестирования, выбрать лучшую версию несложно:
1. Регулярно запускайте автоматизированные тесты на новых релизах ClickHouse. Это можно делать даже для релизов ClickHouse, помеченных как `testing`, но переходить с ними к следующим шагам не рекомендуется.
2. Разверните релиз ClickHouse, прошедший тесты, в предпроизводственной среде и проверьте, что все процессы работают как ожидается.
3. Сообщайте обо всех обнаруженных проблемах в [ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues).
4. Если серьезных проблем не обнаружено, можно безопасно начинать развертывание релиза ClickHouse в продакшн-среде. Дополнительные вложения в автоматизацию постепенного выпуска, реализующую подход, похожий на [канареечные релизы](https://martinfowler.com/bliki/CanaryRelease.html) или [green-blue deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html), могут еще сильнее снизить риск проблем в продакшне.
Как вы, возможно, заметили, в описанном выше подходе нет ничего специфичного для ClickHouse — так поступают с любым элементом инфраструктуры, от которого зависят, если серьезно относятся к своей продакшн-среде.
## Как выбрать между релизами ClickHouse?
Если посмотреть содержимое репозитория пакетов ClickHouse, вы увидите два типа пакетов:
1. `stable`
2. `lts` (долгосрочная поддержка)
Ниже — несколько рекомендаций, которые помогут выбрать между ними:
* `stable` — это тип пакетов, который мы рекомендуем по умолчанию. Они выходят примерно раз в месяц (поэтому новые возможности появляются без большой задержки), а три последних стабильных релиза поддерживаются в плане диагностики и бэкпорта исправлений ошибок.
* `lts` выходят два раза в год и поддерживаются в течение года после первоначального релиза. Они могут быть предпочтительнее `stable` в следующих случаях:
* В вашей компании действуют внутренние политики, которые не допускают частых обновлений или использования ПО, не относящегося к LTS.
* Вы используете ClickHouse в каких-то второстепенных продуктах, где либо не нужны сложные возможности ClickHouse, либо не хватает ресурсов, чтобы поддерживать его в актуальном состоянии.
Многие команды, которые поначалу считают, что лучше выбрать `lts`, в итоге всё равно переходят на `stable` из-за какой-нибудь новой возможности, важной для их продукта.
***
Есть ещё один момент, о котором стоит помнить при обновлении ClickHouse: мы всегда внимательно следим за совместимостью между релизами, но в отдельных случаях сохранять её нецелесообразно, и какие-то мелкие детали могут меняться. Поэтому перед обновлением обязательно проверьте [журнал изменений](/ru/resources/changelogs/oss/2026), чтобы узнать, нет ли там примечаний об обратно несовместимых изменениях.