ClickHouse опубликован: разворачиваем на тестовом стенде и проверяем на 500 млн строк

15 июня на HighLoad++ Яндекс открыл ClickHouse. Код появился на GitHub, пакеты для Ubuntu выложены, документация - та же, что мы читали в мае, только теперь с репозиторием за ней. В мае мы разбирали анонс по документации и оговаривались: посмотрим, когда будет что пощупать. Пощупали.

Установка

Яндекс предоставляет deb-пакеты для Ubuntu 14.04 и 16.04. Добавляешь репозиторий, apt-get install clickhouse-server clickhouse-client - и сервер поднят. Конфиг по умолчанию слушает на 9000 (native protocol) и 8123 (HTTP). На наш тестовый стенд (Ubuntu 16.04, 32 GB RAM, SSD) ClickHouse встал минут за пятнадцать вместе с вдумчивым чтением конфига.

Первый clickhouse-client и SELECT 1 - работает. Создать таблицу MergeTree, вставить пару строк, сделать SELECT - всё из коробки, без танцев с ZooKeeper (он нужен только для репликации, в однонодовом режиме - не обязателен).

Схема для нашего набора данных - события веб-аналитики: дата, идентификатор сессии, страница, тип события, несколько числовых полей. Движок MergeTree с сортировкой по дате.

Загрузка данных

Исходные данные - около 500 млн строк, экспорт из PostgreSQL в TSV. ClickHouse умеет читать TSV через clickhouse-client --query="INSERT INTO events FORMAT TabSeparated" с перенаправлением файла. Загрузка прошла быстрее, чем в PostgreSQL: колоночное хранение с компрессией, вставка кусками (parts), никакой построчной работы с индексами MVCC.

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

Запросы

Вот где началось интересное. Типовой аналитический запрос из текущего проекта - количество событий каждого типа по дням за три месяца:

SELECT
    toDate(event_time) AS day,
    event_type,
    count() AS cnt
FROM events
WHERE event_time >= '2016-03-01' AND event_time < '2016-06-01'
GROUP BY day, event_type
ORDER BY day, event_type;

В PostgreSQL (таблица без партиционирования, индекс по дате): несколько минут, местами больше. Мы смотрели на Spark для таких задач - там другая операционная сложность.

В ClickHouse тот же запрос отработал за секунды. Не за единицы - за несколько. Это другая категория ощущений.

COUNT(*) по всей таблице без WHERE - меньше секунды. SELECT с несколькими агрегатами по нескольким колонкам - тоже секунды. Читается только то, что нужно для запроса: колонки, задействованные в SELECT и WHERE. Остальные не трогаются.

Ограничения, которые стоит знать

Радоваться хорошо, но понимать, за что платишь, - обязательно.

• Нет транзакций. Это архитектурный выбор. ClickHouse - не OLTP. Если нужно атомарно вставить группу строк с откатом при ошибке - это не сюда.
• UPDATE и DELETE не поддерживаются. В базовом сценарии таблица append-only. Удалить или обновить строки средствами SQL нельзя - это архитектурное ограничение. Для исправления ошибок в исторических данных придётся перезаписывать партиции целиком. Для операционной логики - не подходит.
• JOIN с ограничениями. Большие JOIN-ы по двум крупным таблицам - не сильная сторона. Правая таблица загружается в память. Для аналитических запросов с небольшими словарными таблицами - нормально.
• SQL-диалект - свой. Не стандарт. Некоторые функции называются иначе, часть стандартного SQL не поддерживается или поддерживается с нюансами. Переносить запросы из PostgreSQL нужно с проверкой.
• ZooKeeper для репликации. Одна нода работает без него. Кластер с репликацией - нужен ZooKeeper. Если Kafka уже есть и ZooKeeper с ней - делить или дублировать, это вопрос на потом.

Где это применимо

Задача, которую мы проверяли - хранение и агрегация событий веб-аналитики. Данные копятся append-only, исторические записи не меняются, нужны быстрые срезы по времени и измерениям. Это именно то, под что ClickHouse спроектирован.

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

Пока это один стенд и один набор данных. На production идти с таким объёмом тестирования рано. Но первое впечатление - разрыв в скорости агрегаций реальный, не маркетинговый, и установка не требует отдельной команды. Это уже что-то.