ClickHouse: 10 лет открытой разработки аналитической БД

Ключевые факты

• ClickHouse запущена как открытый проект в июне 2016, её корни уходят в экспериментальный прототип 2008 года для обработки веб-аналитики
• Проект определяет четыре уровня открытого исходного кода, от публичного чтения кода до полной прозрачности разработки, включая roadmap, code review и документацию
• ClickHouse реализована полностью с нуля (не поверх PostgreSQL или Datafusion), что делает её редким примером bootstrapped DBMS
• Архитектура использует комбинацию колоночного подхода для скорости агрегации и merge tree для обновлений реального времени с локальностью данных
• Все контрибьюторы упоминаются в changelog и даже в системной таблице system.contributors

Ред. Редкий случай, когда юбилей open-source проекта это не маркетинг, а исторический факт про архитектуру.

Почему это важно

Разработка ClickHouse демонстрирует, как можно создать конкурентоспособную систему управления БД с нуля, опираясь на реальные задачи веб-аналитики. Когда стандартные решения (MySQL, различные OLAP-расширения) не справляются с объёмом в 100 миллиардов записей в день с 500 колонками, нужна специализированная архитектура. Это показывает, что правильная абстракция (колоночное хранилище плюс merge tree) может уходить от фундаментальных проблем производительности лучше, чем попытки оптимизировать универсальное решение.

Ред. То есть "build your own DB" не всегда гибрис; иногда это логичный ответ на перпендикулярные требования.

Кому это важно

Для инженеров, которые проектируют системы обработки больших данных в реальном времени: веб-аналитика, логирование, финансовые данные, события IoT. ClickHouse становится эталоном, как писать code review, тестировать экспериментальные структуры данных, организовать документацию так, чтобы люди учились на исходном коде, а не гуглили по сторонам. Для open-source контрибьюторов это модель кредитования работы (даже если код переписан полностью, первоначальный автор упоминается) формирует культуру, в которой стоит вложиться в проект.

Ред. Правильная атрибуция в системе (system.contributors) это вот копить усталость кодера на уровне SQL, а не в чувствах.

Как это применить

Если вы строите аналитическую систему, посмотрите на эволюцию ClickHouse как на playbook: начните с простейшего прототипа, который работает на вашем наборе данных (OLAPServer, Metrage), затем обобщайте абстракции только когда они перестают расширяться (query language, table engines). ClickHouse использует RecursiveDescent parser вместо boost::spirit, потому что парсер нужен, который работает, а не красивый. Пример: авторы отказались от Variant-колонки в 2009 году из-за медлительности, добавили её обратно в 2025 с другой реализацией. Это означает, что даже в успешных проектах отказы и переделки это норма.

Ред. Удаление ненужного кода в 2026 году уже считается "любимым делом", стандартный переход от молодости к взрослости в архитектуре.

Можно ли доверять

Статья написана первоначальным автором ClickHouse, Алексеем Миловидовым, и опубликована на официальном блоге. История отслеживаема через историю коммитов в репозитории (первый коммит датируется 2009 годом), что можно проверить самостоятельно. Описание уровней open-source (от публичного кода до полной прозрачности разработки) это общепринятая классификация в сообществе. Цифры (2000+ контрибьюторов, 100 млн записей в день, 500 колонок) относятся к историческим случаям и задачам, которые решала система, а не к текущим требованиям.

Ред. У истории есть провенанс: авторство, даты, история репозитория, но цифры в том числе чистые воспоминания, не метрики.

Риски и подводные камни

ClickHouse оптимизирована для очень конкретного класса нагрузок: аналитика на полных таблицах с агрегацией, а не случайные точечные выборки. Если ваша задача требует частых обновлений отдельных строк или высокой зависимости от case-when логики в индексах, OLAP архитектура может оказаться медленнее, чем строчно-ориентированная СУБД. Кроме того, развёртывание и оптимизация ClickHouse требует глубокого понимания её архитектуры. Это не решение "установил и забыл". История протоколирует несколько случаев, когда идеи (fixed-size arrays, Variant в исходном виде) были удалены и переделаны спустя годы, что говорит о том, что даже в зрелом проекте могут быть неправильные абстракции.

Ред. 10 лет и 2000 контрибьюторов не гарантирют, что ваш юзкейс подходит; это гарантирует хорошее тестирование чужих юзкейсов.