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