Какую версию ClickHouse использовать?

Во-первых, давайте обсудим, почему возникает этот вопрос. Есть две основные причины:

1. ClickHouse развивается достаточно быстро, и обычно мы выпускаем более 10 стабильных релизов в год. Так что есть из чего выбрать, а это не всегда просто.
2. Некоторые пользователи не хотят тратить время на анализ того, какая версия лучше подходит для их задач, и просто хотят получить совет от эксперта.

Вторая причина более весомая, так что начнем с нее, а затем рассмотрим, какие бывают релизы ClickHouse.

Какую версию ClickHouse вы посоветуете?

Казалось бы, самый удобный вариант — нанять консультанта или довериться эксперту, и делегировать ему ответственность за вашу систему. Вы устанавливаете ту версию ClickHouse, которую вам рекомендовали, и теперь если что-то пойдет не так — это уже не ваша вина. На самом деле это не так. Никто не может знать лучше вас, что происходит в вашей системе.

Как же правильно выбрать версию ClickHouse, на которую стоит обновиться? Или как выбрать версию, с которой следует начать, если вы только внедряете ClickHouse? Во-первых, мы рекомендуем позаботиться о создании реалистичной тестовой среды (pre-production). В идеальном мире это была бы полная копия рабочей среды, но чаще всего такое решение оказывается слишком дорогостоящим.

Чтобы тестовая среда была достаточно надежной, но не слишком дорогостоящей, учитывайте следующие моменты:

• В тестовой среде нужно выполнять набор запросов, максимально близкий к тому, который будет выполняться в реальной среде:
  • Не используйте тестовую среду в режиме "только для чтения", работая с каким-то статичным набором данных.
  • Не используйте её в режиме "только для записи", проверяя лишь копирование данных, без построения типовых отчетов.
  • Не очищайте её, удаляя все данные подчистую вместо тестирования рабочих схем миграции.
• Выполняйте реальные запросы на выборке из реальных рабочих данных. Постарайтесь подготовить репрезентативную выборку, на которой запрос SELECT будет возвращать адекватные результаты. Если регламенты безопасности не позволяют использовать реальные данные за пределами защищенной рабочей среды, используйте обфускацию.
• Убедитесь, что тестовая среда находится под контролем тех же систем мониторинга и оповещения, что и рабочая.
• Если ваша рабочая среда распределена между разными дата-центрами и регионами, тестовая среда должна быть такой же.
• Если в рабочей среде используются сложные инструменты типа репликации, распределённых таблиц или каскадных материализованных представлений, тестовая среда должна быть сконфигурирована так же.
• Обычно в тестовой среде стараются использовать то же количество серверов и виртуальных машин, что и в рабочей, но делают их меньшего объема. Либо наоборот, используют существенно меньшее число серверов и ВМ, но тех же объемов. Первый вариант скорее позволит обнаружить проблемы, связанные с работой сети, а второй вариант более прост в управлении.

Второе направление — автоматизированное тестирование. Не думайте, что если какой-то запрос отработал успешно один раз, так будет всегда. Считается приемлемым выполнять некоторые юнит-тесты, используя "заглушки" вместо запросов к СУБД. Но вы должны проводить достаточное количество автотестов, где запросы выполняются в реальном ClickHouse, чтобы убедиться, что все важные задачи отрабатывают должным образом.

В продолжение этой темы, вы можете поделиться вашими автотестами и передать их в открытую тестовую среду ClickHouse, которая используется для постоянного развития нашей СУБД. Вам придётся потратить немного времени и сил, чтобы научиться составлять и выполнять тесты, а также чтобы перенести ваши тесты на эту платформу. Наградой за это станет уверенность в том, что новые стабильные релизы ClickHouse будут корректно работать на ваших задачах. Это гораздо лучше, чем тратить время на то, чтобы вновь отлавливать прежние ошибки в новых версиях, а затем ждать, пока их исправят и включат эти исправления в очередной релиз. Некоторые компании уже включили в корпоративные регламенты необходимость передачи своих тестов в ClickHouse, прежде всего стоит упомянуть правило Beyonce, действующее в Google.

После того, как вы подготовили тестовую среду и инфраструктуру, выбор версии ClickHouse упрощается:

1. Проверяйте новые релизы ClickHouse с помощью подготовленных автотестов. Вы можете проверять не только стабильные релизы, но и тестовые, хотя работать с такими релизами не рекомендуется.
2. Если новый релиз ClickHouse успешно прошел ваши автотесты, внедряйте его в тестовой среде и проверяйте работоспособность всех ваших задач.
3. Сообщайте обо всех обнаруженных проблемах в ClickHouse GitHub Issues.
4. Если никаких серьезных проблем не было выявлено, можно установить новый релиз ClickHouse в рабочую среду. Чтобы еще больше снизить риски, вы можете внедрить специальные техники поэтапного перехода на новые релизы, такие как canary releases или green-blue deployments.

Как вы уже поняли, ClickHouse не требует какого-то особенного подхода — описанные выше правила широко используются для любых элементов инфраструктуры, если нужно обеспечить ее надежность и если компании серьезно подходят к вопросам стабильности своих систем.

Какой вид релиза ClickHouse выбрать?

Если вы заглянете в раздел, где публикуются установочные пакеты ClickHouse, вы увидите там следующие виды пакетов:

1. stable
2. lts (long-term support)

В рабочей среде мы рекомендуем использвать либо стабильный релиз (stable), либо релиз с долговременной поддержкой (lts). Если вы выбираете между этими двумя видами релизов, примите во внимание следующее:

• По умолчанию мы рекомендуем релизы stable. Новый стабильный релиз выпускается примерно раз в месяц, что открывает доступ к новым функциям. Три последних стабильных релиза находятся на поддержке — это означает, что в них интегрируются исправленные ошибки и доработки.
• Релизы lts выпускаются дважды в год и находятся на поддержке в течение года с момента выхода. Они более предпочтительны в следующих случаях:
  • ваши корпоративные регламенты запрещают частые обновления или использование любых релизов, кроме LTS;
  • вы используете ClickHouse в продуктах, которые не задействуют сложные инструменты ClickHouse, или у вас не хватает ресурсов для частого их обновления.

Часто компании, которые изначально ориентировались на релизы lts, позднее переходят на stable, поскольку хотят быстрее получать доступ к новым возможностям.

Важно

Мы всегда стремимся поддерживать совместимость релизов, но иногда это правило нарушается, и какие-то отдельные возможности в новых релизах становятся недоступны. Перед обновлением ClickHouse обязательно изучите журнал изменений, чтобы убедиться, что в нем нет объявлений о нарушении обратной совместимости.