Почему ClickHouse такой быстрый?

Многие другие факторы способствуют производительности базы данных, помимо его ориентации данных. В следующем мы подробнее объясним, что делает ClickHouse таким быстрым, особенно по сравнению с другими столбцовыми базами данных.

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

Слой хранения: Параллельные вставки изолированы друг от друга

В ClickHouse каждая таблица состоит из нескольких "частей таблицы". Часть создается при каждом внесении пользователем данных в таблицу (оператор INSERT). Запрос всегда выполняется по всем частям таблицы, которые существуют на момент начала выполнения запроса.

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

Этот подход имеет несколько преимуществ: Вся обработка данных может быть перенесена на фоновые слияния частей, что позволяет оставлять записи данных легковесными и высокоэффективными. Индивидуальные вставки являются "локальными" в том смысле, что им не нужно обновлять глобальные, т.е. структуры данных по всей таблице. В результате множественные одновременные вставки не требуют взаимной синхронизации или синхронизации с существующими данными таблицы, и следовательно, вставки могут выполняться почти со скоростью ввода-вывода диска.

как это описано в разделе общего оптимизации производительности статьи VLDB.

🤿 Углубитесь в это в разделе On-Disk Format веб-версии нашей статьи VLDB 2024.

Слой хранения: Параллельные вставки и выборки изолированы

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

🤿 Углубитесь в это в разделе Storage Layer веб-версии нашей статьи VLDB 2024.

Слой хранения: Вычисление во время слияния

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

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

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

• Слияния TTL (time-to-live), которые сжимают, перемещают или удаляют строки на основе определенных временных правил.

Цель этих преобразований заключается в том, чтобы перенести работу (вычисления) с момента выполнения запросов пользователей на время слияния. Это важно по двум причинам:

С одной стороны, запросы пользователей могут стать значительно быстрее, иногда в 1000 раз и более, если они могут использовать "преобразованные" данные, например, предварительно агрегированные данные.

С другой стороны, большинство времени выполнения слияния занимает загрузка входных частей и сохранение выходной части. Дополнительные усилия для преобразования данных во время слияния обычно не влияет на время выполнения слияния слишком сильно. Все это волшебство полностью прозрачно и не влияет на результаты запросов (кроме их производительности).

🤿 Углубитесь в это в разделе Merge-time Data Transformation веб-версии нашей статьи VLDB 2024.

Слой хранения: Прореживание данных

На практике многие запросы являются повторяющимися, т.е. выполняются без изменений или только с небольшими модификациями (например, с разными значениями параметров) через определенные интервалы времени. Выполняя одни и те же или подобные запросы снова и снова, можно добавлять индексы или реорганизовывать данные таким образом, чтобы частые запросы могли быстрее к ним обращаться. Этот подход также известен как "прореживание данных", и ClickHouse предоставляет три техники для этого:

1. Индексы первичного ключа, которые определяют порядок сортировки данных в таблице. Хорошо выбранный первичный ключ позволяет оценивать фильтры (такие как условия WHERE в приведенном выше запросе) с использованием быстрых бинарных поисков вместо полных сканирований колонок. В более технических терминах время выполнения сканирования становится логарифмическим, а не линейным по размеру данных.

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

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

Все три техники направлены на то, чтобы пропустить как можно больше строк во время чтения полных колонок, поскольку самый быстрый способ прочитать данные – это вовсе не читать их.

🤿 Углубитесь в это в разделе Data Pruning веб-версии нашей статьи VLDB 2024.

Слой хранения: Сжатие данных

Кроме того, слой хранения ClickHouse также (и необязательно) сжимает сырые данные таблицы, используя различные кодеки.

Столбцовые хранилища особенно хорошо подходят для такого сжатия, так как значения одного типа и распределение данных расположены вместе.

Пользователи могут указать, что колонки сжимаются с помощью различных универсальных алгоритмов сжатия (таких как ZSTD) или специализированных кодеков, например, Gorilla и FPC для значений с плавающей запятой, Delta и GCD для целых чисел или даже AES в качестве кодека для шифрования.

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

🤿 Углубитесь в это в разделе On-Disk Format веб-версии нашей статьи VLDB 2024.

Современный слой обработки запросов

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

"Векторизация" означает, что операторы плана запроса передают промежуточные строки результата порциями, а не по одной строке. Это ведет к лучшему использованию кешей CPU и позволяет операторам применять инструкции SIMD для обработки нескольких значений одновременно. На самом деле, многие операторы имеют множество версий - по одной для каждого набора инструкций SIMD. ClickHouse автоматически выберет самую последнюю и быструю версию в зависимости от возможностей оборудования, на котором он работает.

Современные системы имеют десятки ядер CPU. Чтобы использовать все ядра, ClickHouse разворачивает план запроса на несколько линий, обычно по одной на каждое ядро. Каждая линия обрабатывает несоприкасающийся диапазон данных таблицы. Таким образом, производительность базы данных масштабируется "вертикально" с количеством доступных ядер.

Если один узел становится слишком маленьким, чтобы вмещать данные таблицы, можно добавить дополнительные узлы для формирования кластера. Таблицы могут быть разделены ("шардированы") и распределены по узлам. ClickHouse будет выполнять запросы на всех узлах, которые хранят данные таблицы, тем самым масштабируя "горизонтально" с количеством доступных узлов.

🤿 Углубитесь в это в разделе Query Processing Layer веб-версии нашей статьи VLDB 2024.

Тщательное внимание к деталям

"ClickHouse - это необычная система - у вас, ребята, 20 версий хеш-таблицы. У вас есть все эти удивительные вещи, которые есть только у одной хеш-таблицы в большинстве систем... ClickHouse имеет такую удивительную производительность, потому что у него есть все эти специализированные компоненты" Энди Павло, профессор баз данных в CMU

Что отличает ClickHouse от других - это тщательное внимание к оптимизации на низком уровне. Создание базы данных, которая просто работает, это одно, но проектирование ее для обеспечения скорости при различных типах запросов, структурах данных, распределениях и конфигурациях индексов - это то, где сияет искусство "необычной системы".

Хеш-таблицы. В качестве примера рассмотрим хеш-таблицу. Хеш-таблицы являются центральными структурами данных, используемыми в операциях joins и агрегациях. Как программист, вам необходимо учитывать следующие проектные решения:

• Какую хеш-функцию выбрать,
• Разрешение коллизий: открытая адресация или цепочечная хеш-таблица,
• Макет памяти: один массив для ключей и значений или отдельные массивы?
• Фактор заполнения: Когда и как изменять размер? Как перемещать значения при изменении размера?
• Удаления: Должна ли хеш-таблица разрешать удаление записей?

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

Реализация хеш-таблицы в ClickHouse выбирает одну из 30+ заранее скомпилированных различных вариантов хеш-таблиц, основываясь на специфике запроса и данных.

Алгоритмы. То же самое справедливо и для алгоритмов. Например, при сортировке вы можете учитывать:

• Что будет сортироваться: числа, кортежи, строки или структуры?
• Данные находятся в ОЗУ?
• Требуется ли, чтобы сортировка была стабильной?
• Должны ли все данные быть отсортированы или достаточно частичной сортировки?

Алгоритмы, полагающиеся на характеристики данных, часто работают лучше, чем их универсальные собраты. Если характеристики данных заранее не известны, система может попробовать различные реализации и выбрать ту, которая работает лучше всего во время выполнения. Например, смотрите статью о том, как реализовано распаковка LZ4 в ClickHouse.

🤿 Углубитесь в это в разделе Holistic Performance Optimization веб-версии нашей статьи VLDB 2024.

Статья VLDB 2024

В августе 2024 года наша первая исследовательская работа была принята и опубликована на VLDB. VLDB - это международная конференция по очень большим базам данных и считается одной из ведущих конференций в области управления данными. Среди сотен заявок VLDB обычно имеет уровень приема около 20%.

Вы можете прочитать PDF-копию статьи или нашу веб-версию этой статьи, которая содержит краткое описание наиболее интересных архитектурных и системных компонентов ClickHouse, которые делают его таким быстрым.

Алексей Миловидов, наш технический директор и создатель ClickHouse, представил статью (слайды здесь), после чего последовал вопрос-ответ (который быстро вышел за пределы времени!). Вы можете посмотреть записанную презентацию здесь: