Основатель 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.

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

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 API, BQN, Elasticsearch, MongoDB или LogsQL.

Итоги

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

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

Глубже разобраться в нагрузочном тестировании и производительности СУБД можно на бесплатных демо-уроках:

13 августа, 20:00. «Минимум для старта: как провести своё первое нагрузочное тестирование». Записаться
1 сентября, 20:00. «PostgreSQL 18: асинхронный ввод-вывод и io_uring на практике». Записаться

ссылка на оригинал статьи https://habr.com/ru/articles/1066464/