Основатель ClickHouse собрал 110 СУБД в одной интерактивной песочнице

Создатель ClickHouse Алексей Миловидов запустил ClickBench Playground — интерактивную площадку, на которой можно работать свыше со ста СУБД.

Потребитель может выбрать нужную систему, выполнять запросы, создавать базы данных и таблицы, скачивать данные и удалять объекты. В каждой СУБД заранее размещён набор из 100 млн записей, поэтому проверять запросы можно сразу, без предварительной подготовки окружения.

На площадке представлены не только реляционные базы данных, но и менее привычные системы, включая решения из других областей — в частности, язык массивов BQN.

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

В соответствии с заявлению Миловидова, это крупнейшая интерактивная коллекция СУБД. Похожие возможности предоставляют sqlfiddle, db-fiddle и codapi, однако количество поддерживаемых систем там заметно меньше.

Как это стало возможным

От ClickBench к интерактивной площадке

Инициатива вырос из ClickBench — набора тестов, который появился в 2013 году для сравнения производительности ClickHouse. В 2022 году его превратили в открытый проверка для аналитических СУБД.

Одна из основных задач проекта — максимально упростить добавление новых систем. Для каждой СУБД в репозитории создаётся отдельный каталог с несколькими сценариями командной оболочки.

Основной скрипт устанавливает систему, загружает и импортирует данные, запускает тесты, а затем сохраняет результаты. Обычно его вручную выполняют на новой виртуальной машине Amazon EC2. Для облачных СУБД вместо сценария добавляют пошаговую инструкцию.

Такой решение позволяет учитывать особенности отдельных систем. Например, СУБД можно запустить в Docker, если она не работает в стандартном образе Ubuntu, или отдельно настроить необходимую версию JVM.

В итоге ClickBench удалось сохранить по сравнению с простым и открытым для внешних участников. Сейчас инициатива используется как публичный набор тестов для сравнения аналитических СУБД.

Проблемы сопровождения

Поддерживать в актуальном состоянии сотню сценариев командной оболочки оказалось сложнее, чем запустить их один раз. Результаты со временем устаревают, тесты приходится повторять, а любое модификация — свежий набор запросов или иной адрес загрузки данных — требует заново прогонять все системы.

Летом 2025 года Миловидов внедрил автоматизацию на основе cloud-init. Она даёт возможность развернуть виртуальную машину и запустить тестирование без участия пользователя. Сценарий формирует журналы в заданном формате и отправляет их в сервис ClickHouse, а отдельная программа находит новые результаты и обновляет репозиторий.

После этого пришлось проверить и исправить все существующие сценарии, чтобы они снова выполнялись без ошибок.

Следующая проблема возникла при попытке расширить ClickBench. Все сценарии делали примерно одно и то же — загружали набор данных и выполняли запросы, — но каждый немного по-своему. Следовательно добавление нового набора данных, запросов или отдельного теста требовало изменений сразу в сотне файлов.

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

Чтобы результаты холодных запросов оставались сопоставимыми, авторы решили перезапускать каждую систему перед измерением. Однако добавить одинаковую процедуру перезапуска в сотню различающихся сценариев было непросто.

Общий интерфейс для всех систем

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

Некоторое количество попыток провести такую переработку вручную не дали результата. Позже для этой задачи применили инструменты на основе ИИ, и после нескольких итераций все сценарии удалось привести к общей схеме.

Дополнительную сложность создавало разнообразие участников ClickBench. В инициатива входят не только полноценные СУБД с сервером, но и встраиваемые движки, библиотеки и инструменты анализа данных.

В частности, DataFusion и DuckDB можно использовать как основу для собственного SQL-движка, а Pandas и Polars представляют собой библиотеки обработки данных. Чтобы запускать их по единой методике, такие системы оборачивают в HTTP-сервер на Python. За счёт этому каждый запрос можно выполнять отдельно, как и в обычной серверной СУБД.

Подробнее об истории изменений ClickBench автор предлагает читать в журнале проекта.

Новые возможности

После унификации интерфейсов все системы можно скачивать и тестировать по одной схеме, даже если формат таблиц, способ импорта и набор запросов у них различаются.

Это позволило расширить тестирование. Автор увеличивал объём данных, добавлял больше запросов с JOIN, оконными функциями и коррелированными подзапросами, проверял параллельное выполнение и запускал системы на разных конфигурациях AWS — от машин с 2 ГБ памяти до серверов со 192 процессорами, в том числе AMD64 и ARM.

Эксперименты показали, что некоторые решения были оптимизированы под стандартные запросы ClickBench и теряли позиции при более широком наборе задач. Другие плохо работали с большими объёмами данных или параллельной нагрузкой.

Следующим шагом стала идея оставить все системы запущенными и дать пользователям функция выполнять запросы напрямую. Так появился ClickBench Playground.

Новые возможности

После унификации интерфейсов все системы можно загружать и тестировать по одной схеме, даже если формат таблиц, способ импорта и набор запросов у них различаются.

Это позволило расширить тестирование. Автор увеличивал объём данных, добавлял больше запросов с JOIN, оконными функциями и коррелированными подзапросами, проверял параллельное выполнение и запускал системы на разных конфигурациях AWS — от машин с 2 ГБ памяти до серверов со 192 процессорами, включая AMD64 и ARM.

Эксперименты показали, что некоторые решения были оптимизированы под стандартные запросы ClickBench и теряли позиции при более широком наборе задач. Другие плохо работали с большими объёмами данных или параллельной нагрузкой.

Следующим шагом стала идея оставить все системы запущенными и дать пользователям возможность выполнять запросы напрямую. Так появился ClickBench Playground.

ClickBench Playground

Главная проблема заключалась в том, чтобы разместить приблизительно сотни СУБД недорого и одновременно безопасно.

Постоянно держать для каждой системы отдельную машину AWS EC2 оказалось слишком дорого: годовая стоимость превысила бы $500 тыс. Запускать машины по требованию тоже неудобно — развёртывание занимает от десятков секунд до нескольких минут, что плохо подходит для интерактивного сервиса.

AWS Lambda не подошла в связи с ограничений на размер образов и сложностей с хранением большого набора данных. ECS и EKS равным образом не решали проблему: часть систем уже работает внутри Docker, а сохранение состояния и быстрый запускание контейнеров организовать сложно. Кроме того, эти сервисы не давали заметной экономии по сравнению с EC2.

Разместить все СУБД на одном сервере без изоляции тоже нельзя. Любая платформа может исчерпать память, занять всё дисковое пространство, загрузить чип или стать точкой входа для атаки. Docker ограничивает ресурсы, но не обеспечивает достаточную защиту, особенно когда внутри контейнера требуется запускать другие контейнеры.

В итоге автор выбрал полноценную виртуализацию с QEMU и Firecracker. Для этого используется физический сервер AWS EC2 Metal, внутри которого запускаются небольшие виртуальные машины для отдельных СУБД. По сути, ClickBench Playground представляет собой небольшое облако, развёрнутое внутри инфраструктуры AWS.

Как распределяются ресурсы

Даже самый крупный сервер не может выделить каждой из ста виртуальных машин по 16 ГБ памяти, нескольку процессорных ядер и сотни гигабайт диска. Следовательно ресурсы распределяются динамически.

Чип

Каждая виртуальная машина получает до четырёх ядер. Если несколько систем одновременно создают нагрузку, процессорное время между ними распределяет планировщик главный ОС. Отдельный контроллер завершает машины, которые слишком долго загружают чип.

Память

Firecracker выделяет память лениво: виртуальная машина может видеть 16 ГБ, но физически занимает только реально используемый объём.

Для Pandas, Polars и других систем, загружающих весь набор данных в хранилище, используется файл подкачки на виртуальном диске. Пока на основном сервере в достаточной степени памяти, информация фактически остаются в его страничном кеше, следовательно такая схема работает быстрее обычного обращения к диску.

Дисковое пространство

Снимки всех систем наряду с данными могли бы занять около 100 ТБ, тогда как локальные диски выбранного сервера вмещают только 7,5 ТБ.

Сначала автор использовал разреженные файлы и алгоритм copy-on-write, чтобы не хранить пустые блоки и не дублировать снимки. Затем перешёл на Btrfs, которая поддерживает и ссылки на общие блоки, и сжатие Zstandard. В итоге все сто систем удалось разместить на 7,5 ТБ, сохранив оперативный запускание из снимков.

Сеть

Доступ в интернет разрешён только при создании образа, когда нужно установить СУБД и загрузить зависимости. После восстановления виртуальной машины из снимка внешняя сеть отключается, поэтому пользовательские запросы выполняются в изолированном окружении.

Ограниченный доступ в интернет

Часть тестов ClickBench работает с удалёнными данными — Parquet-файлами в S3 или наборами на HTTP-серверах. Следовательно некоторым виртуальным машинам нужен доступ в интернет даже во время выполнения запросов.

Открывать сеть напрямую небезопасно: гостевая платформа могла бы обратиться к сервисам основного сервера или службе метаданных AWS IMDS.

Каждая виртуальная машина получает частный IP-адрес и виртуальный сетевой оболочку. Маршрутизацию и преобразование адресов на основном сервере выполняет iptables.

Весь исходящий посещаемость проходит через прокси с разрешённым списком узлов. Он пропускает DNS, HTTP и HTTPS только к необходимым ресурсам. Для фильтрации HTTPS используется открытое поле SNI, содержащее имя запрашиваемого сервера, поэтому расшифровывать трафик и подменять сертификаты не требуется.

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

Оперативный запуск и сброс состояния

Снимки содержат уже запущенные процессы СУБД, следовательно даже образы размером в сотни гигабайт восстанавливаются не более за пять секунд.

После ошибки запроса виртуальная машина пересоздаётся из снимка. Пользователь может удалить таблицу или остановить сервер, но второй сеанс начнётся с исходного состояния.

Сравнение языков запросов

Playground позволяет сравнивать способы решения одной задачи в разных системах. При переключении между СУБД оболочку демонстрирует соответствующий пример запроса — на SQL, через DataFrame программный интерфейс, BQN, Elasticsearch, MongoDB или LogsQL.

Итоги

Миловидов создавал служба в первую очередь как площадку для собственной коллекции СУБД — популярных, экспериментальных и малоизвестных.

ClickBench Playground можно применять для сравнения поведения систем, поддержки стандартов и синтаксиса запросов. Помимо этого, проект стал инструментом для дальнейшего развития ClickHouse и ClickBench.