ClickHouse выходит в open-source: Яндекс анонсирует колоночную OLAP-СУБД

Несколько дней назад в профессиональном чате всплыл скриншот: Яндекс собирается выпустить свою внутреннюю СУБД для аналитики в open-source. Называется ClickHouse, заявлена как колоночная OLAP-система, открытие - на HighLoad++ в июне. Пока это слухи и анонс без кода, но документацию Яндекс уже начал публиковать - и мы её прочитали.

Что такое ClickHouse по документации

Яндекс описывает ClickHouse как СУБД для онлайн-аналитики (OLAP) с колоночным хранением. Ключевая идея - данные на диске хранятся не построчно (как в PostgreSQL или MS SQL), а по столбцам. Для аналитических запросов вида «сумма по полю X за период» это существенно: читается только нужный столбец, а не вся строка целиком.

Это не новая концепция. Vertica, Greenplum, Amazon Redshift - все они используют колоночное хранение. Новость в другом: ClickHouse заявлен как то, что Яндекс годами гонял под реальными нагрузками Метрики, и теперь это выходит в open-source.

Из документации складывается вот что:

• Колоночное хранение с компрессией. Каждый столбец хранится отдельным файлом, сжатие применяется пер-столбец. Однотипные данные в одном столбце сжимаются лучше, чем вперемешку в строке.
• MergeTree - основной движок. Данные пишутся кусками (parts), потом фоново сливаются (merge). Схема напоминает LSM-деревья, но заточена под аналитику, а не под обновления.
• Нет транзакций. ClickHouse не OLTP. DELETE и UPDATE либо ограничены, либо вообще не в базовом сценарии. Это append-only история: вставил - потом читаешь.
• SQL-диалект. Не полный SQL, но большая его часть для SELECT, агрегаций, JOIN-ов.
• Горизонтальное масштабирование. Шардирование из коробки, репликация через ZooKeeper.

Почему это интересно именно сейчас

У нас несколько проектов, где аналитика событий живёт в PostgreSQL - и это терпимо, пока объёмы небольшие. Мы запустили Kafka как шину событий и смотрели на Kafka Streams для агрегаций. Следующий вопрос, который закономерно встаёт: куда складывать события для долгосрочного хранения и исторических срезов?

PostgreSQL с хорошей индексацией и партиционированием справляется. Но колоночная СУБД для этого класса задач - другая категория. Запрос «посчитай количество уникальных пользователей по часам за последние три месяца» в строковой базе - это скан большого объёма данных с агрегацией. В колоночной - читается только нужный столбец, агрегация векторизованная.

Vertica мы рассматривали. Redshift - облако, а у ряда клиентов данные должны оставаться on-premise. Greenplum - тяжёлая инфраструктура. ClickHouse, если документация не врёт, должен быть легче в развёртывании.

Что смущает на этапе документации

Код не открыт ещё - это нужно держать в голове. Оцениваем то, что задокументировано.

Отсутствие обновлений - это архитектурный выбор, а не недоработка. Для аналитики событий (логи, клики, метрики) это нормально: события не меняются, только накапливаются. Но если задача предполагает корректировки исторических данных - надо думать, как с этим жить.

ZooKeeper как зависимость для репликации. Мы уже встречали это с Kafka - ZooKeeper сам по себе требует отдельного внимания. Добавлять ещё один ZooKeeper-кластер или делить его между Kafka и ClickHouse - оба варианта имеют свои нюансы.

SQL-диалект - своя реализация, не стандарт. Надо будет проверять, насколько запросы из существующих отчётов совместимы.

Документация на русском - это пока основной источник. Для внутренней команды нормально, для внешнего сообщества - посмотрим, как будет развиваться после открытия.

Что планируем

Ждём июня и открытия кода. Задача минимум - развернуть на тестовом стенде и прогнать несколько запросов на реальном наборе данных из одного из текущих проектов: события из Kafka, несколько сотен миллионов строк, типовые агрегационные запросы аналитиков.

Сравнить хочется с тем, как то же самое работает в PostgreSQL на секционированных таблицах. Не синтетический тест, а конкретный запрос из продакшна.

Для аналитических проектов разрыв между «колоночная СУБД» и «строковая СУБД с индексами» в документации выглядит убедительно. Как это работает на реальном железе - покажет только тест. Напишем, когда будет что рассказать.