Почему ClickHouse такой быстрый?
Многие другие факторы влияют на производительность базы данных помимо ее ориентации на данные. В следующем разделе мы подробнее объясним, что делает ClickHouse таким быстрым, особенно по сравнению с другими столбцовыми базами данных.
С архитектурной точки зрения, базы данных состоят (по крайней мере) из слоя хранения и слоя обработки запросов. В то время как слой хранения отвечает за сохранение, загрузку и поддержку данных таблицы, слой обработки запросов выполняет запросы пользователя. По сравнению с другими базами данных, ClickHouse предлагает инновации на обоих уровнях, которые обеспечивают чрезвычайно быстрые вставки и запросы SELECT.
Слой хранения: параллельные вставки изолированы друг от друга
В ClickHouse каждая таблица состоит из нескольких "частей таблиц". Часть создается каждый раз, когда пользователь вставляет данные в таблицу (выражение INSERT). Запрос всегда выполняется против всех частей таблицы, существующих на момент его начала.
Чтобы избежать накопления слишком большого количества частей, ClickHouse выполняет операцию слияния в фоновом режиме, которая постоянно объединяет несколько меньших частей в одну большую.
Этот подход имеет несколько преимуществ: вся обработка данных может быть выгружена на фоновые операции слияния частей, что делает записи данных легковесными и altamente эффективными. Индивидуальные вставки являются "локальными", поскольку им не нужно обновлять глобальные, то есть составные структуры данных. В результате несколько одновременных вставок не требуют взаимной синхронизации или синхронизации с существующими данными таблицы, и, следовательно, вставки могут выполняться почти с той же скоростью, что и ввод-вывод диска.
секции оптимизации производительности в статье VLDB.
🤿 Углубитесь в это в разделе Формат на диске веб-версии нашей статьи VLDB 2024.
Слой хранения: параллельные вставки и выборки изолированы
Вставки полностью изолированы от запросов SELECT, а слияние вставленных частей данных происходит в фоновом режиме без влияния на одновременные запросы.
🤿 Углубитесь в это в разделе Слой хранения веб-версии нашей статьи VLDB 2024.
Слой хранения: вычисление времени слияния
В отличие от других баз данных, ClickHouse сохраняет записи данных легковесными и эффективными, выполняя все дополнительные преобразования данных во время фонового процесса слияния. Примеры этого включают:
-
Слияние замены, которое сохраняет только последнюю версию строки во входных частях и отбрасывает все другие версии строк. Слияние замены можно рассматривать как операцию очистки во времени слияния.
-
Агрегационное слияние, которое объединяет промежуточные состояния агрегации во входной части в новое состояние агрегации. Хотя это может показаться сложным для понимания, на самом деле это реализует инкрементную агрегацию.
-
Слияние TTL (время жизни), которое сжимает, перемещает или удаляет строки на основе определенных временных правил.
Суть этих преобразований заключается в том, чтобы перенести работу (вычисления) из времени выполнения запросов пользователя на время слияния. Это важно по двум причинам:
С одной стороны, запросы пользователя могут стать значительно быстрее, иногда на 1000 раз и более, если они могут использовать "преобразованные" данные, например, предагрегированные данные.
С другой стороны, большая часть времени выполнения слияний затрачивается на загрузку входных частей и сохранение выходной части. Дополнительные затраты на преобразование данных во время слияния, как правило, не влияют слишком сильно на время выполнения слияния. Все эти чудеса полностью прозрачны и не отражаются на результате запросов (кроме их производительности).
🤿 Углубитесь в это в разделе Преобразование данных во время слияния веб-версии нашей статьи VLDB 2024.
Слой хранения: обрезка данных
На практике многие запросы являются повторяющимися, т.е. выполняются без изменений или только с незначительными модификациями (например, с разными значениями параметров) в периодических интервалах. Выполнение одних и тех же или аналогичных запросов снова и снова позволяет добавлять индексы или реорганизовывать данные таким образом, чтобы частые запросы могли обращаться к ним быстрее. Этот подход также известен как "обрезка данных", и ClickHouse предоставляет три техники для этого:
-
Индексы первичного ключа, которые определяют порядок сортировки данных таблицы. Хорошо подобранный первичный ключ позволяет оценивать фильтры (например, условия WHERE в вышеупомянутом запросе) с помощью быстрых бинарных поисков вместо полных сканирований колонок. Более технически, время выполнения сканирования становится логарифмическим, а не линейным по объему данных.
-
Проекции таблиц как альтернативные внутренние версии таблицы, хранящие те же данные, но отсортированные по другому первичному ключу. Проекции могут быть полезны, когда существует более одного частого условия фильтрации.
-
Индексы пропуска, которые встраивают дополнительные статистические данные в колонки, например, минимальное и максимальное значение в колонке, набор уникальных значений и т.д. Индексы пропуска являются ортогональными к первичным ключам и проекциям таблиц, и в зависимости от распределения данных в колонке они могут значительно ускорить оценку фильтров.
Все три техники направлены на то, чтобы пропустить как можно больше строк при полном чтении колонок, поскольку самый быстрый способ прочитать данные — не читать их вовсе.
🤿 Углубитесь в это в разделе Обрезка данных веб-версии нашей статьи VLDB 2024.
Слой хранения: сжатие данных
Кроме того, слой хранения ClickHouse дополнительно (и по желанию) сжимает необработанные данные таблицы с использованием различных кодеков.
Столбцовые хранилища особенно хорошо подходят для такого сжатия, так как значения одного типа и распределения данных расположены вместе.
Пользователи могут указать, что колонки сжимаются с использованием различных общих алгоритмов сжатия (таких как ZSTD) или специализированных кодеков, например, Gorilla и FPC для значений с плавающей точкой, Delta и GCD для целых значений или даже AES как шифрующего кодека.
Сжатие данных не только снижает размер хранения таблиц базы данных, но и во многих случаях улучшает производительность запросов, так как локальные диски и ввод-вывод по сети часто ограничены низкой пропускной способностью.
🤿 Углубитесь в это в разделе Формат на диске веб-версии нашей статьи VLDB 2024.
Современный слой обработки запросов
Наконец, ClickHouse использует векторизованный слой обработки запросов, который по максимуму параллелит выполнение запросов, чтобы использовать все ресурсы для максимальной скорости и эффективности.
"Векторизация" означает, что операторы плана запроса передают промежуточные строки результата пакетами, а не по одной. Это приводит к лучшему использованию кэшей CPU и позволяет операторам применять инструкции SIMD для обработки нескольких значений одновременно. На самом деле, многие операторы представлены в нескольких версиях - по одной для каждого поколения набора инструкций SIMD. ClickHouse автоматически выберет самую последнюю и быструю версию на основе возможностей оборудования, на котором он работает.
Современные системы имеют десятки ядер CPU. Чтобы использовать все ядра, ClickHouse разворачивает план запроса на несколько путей, обычно по одному на ядро. Каждый путь обрабатывает неперекрывающийся диапазон данных таблицы. Таким образом, производительность базы данных масштабируется "вертикально" с увеличением числа доступных ядер.
Если один узел становится слишком мал, чтобы вмещать данные таблицы, можно добавить дополнительные узлы для формирования кластера. Таблицы могут быть разбиты ("шардированы") и распределены по узлам. ClickHouse будет выполнять запросы на всех узлах, которые хранят данные таблицы, и тем самым масштабироваться "горизонтально" с увеличением числа доступных узлов.
🤿 Углубитесь в это в разделе Слой обработки запросов веб-версии нашей статьи VLDB 2024.
Тщательное внимание к деталям
"ClickHouse - это необычная система - у вас 20 версий хеш-таблицы. У вас есть все эти удивительные вещи, в то время как большинство систем имеют одну хеш-таблицу... ClickHouse имеет такое удивительное быстродействие, потому что имеет все эти специализированные компоненты" Энди Павло, профессор баз данных в CMU
Что отличает ClickHouse от других - это тщательное внимание к низкоуровневой оптимизации. Построить базу данных, которая просто работает, - это одно, но спроектировать ее так, чтобы она обеспечивала скорость для различных типов запросов, структур данных, распределений и конфигураций индексов - вот где проявляется искусство "необычной системы".
Хеш-таблицы. Давайте возьмем хеш-таблицу в качестве примера. Хеш-таблицы - это центральные структуры данных, используемые при соединениях и агрегациях. Как программист, необходимо учитывать следующие дизайнерские решения:
- Какую хеш-функцию выбрать,
- Разрешение коллизий: открытое адресование или цепочка,
- Макет памяти: один массив для ключей и значений или отдельные массивы?
- Фактор заполнения: Когда и как изменять размер? Как перемещать значения при изменении размера?
- Удаления: Должна ли хеш-таблица позволять удаление записей?
Стандартная хеш-таблица, предоставленная сторонней библиотекой, будет функционально работать, но не будет быстрой. Для достижения высокой производительности требуется тщательное бенчмаркинг и экспериментирование.
Реализация хеш-таблицы в ClickHouse выбирает одну из 30+ предкомпилированных вариантов хеш-таблицы на основе специфики запроса и данных.
Алгоритмы. То же самое касается и алгоритмов. Например, при сортировке вам может потребоваться учитывать:
- Что будет отсортировано: числа, кортежи, строки или структуры?
- Находятся ли данные в RAM?
- Должна ли сортировка быть стабильной?
- Следует ли сортировать все данные или частичная сортировка будет достаточной?
Алгоритмы, которые зависят от характеристик данных, часто работают лучше своих универсальных аналогов. Если характеристики данных заранее неизвестны, система может попробовать различные реализации и выбрать ту, которая лучше всего работает в реальном времени. Например, вы можете ознакомиться со статьей о том, как в ClickHouse реализовано декомпрессирование LZ4.
🤿 Углубитесь в это в разделе Голистическая оптимизация производительности веб-версии нашей статьи VLDB 2024.
Статья VLDB 2024
В августе 2024 года наша первая исследовательская статья была принята и опубликована на конференции VLDB. VLDB - это международная конференция по очень большим базам данных и считается одной из ведущих конференций в области управления данными. Среди сотен заявок на конференцию общее количество принятых заявок составляет около 20%.
Вы можете прочитать PDF версии статьи или нашу веб-версию, которая дает сжатое описание самых интересных архитектурных и системных компонентов ClickHouse, которые обеспечивают его быстроту.
Алексей Миливодов, наш технический директор и создатель ClickHouse, представил статью (слайды здесь), после чего состоялся вопросно-ответный сеанс (который быстро закончился!). Вы можете посмотреть записанную презентацию здесь:
