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

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

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

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

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

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

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

holistic performance optimization section of the VLDB paper.

🤿 Более подробно об этом в разделе On-Disk Format веб-версии нашей статьи для VLDB 2024.

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

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

🤿 Более подробно об этом в разделе Storage Layer веб-версии нашей статьи для VLDB 2024.

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

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

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

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

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

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

С одной стороны, пользовательские запросы могут стать значительно быстрее, иногда в 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 автоматически выберет самую последнюю и быструю версию, основываясь на возможностях аппаратного обеспечения, на котором он работает.

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

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

🤿 Более подробно об этом в разделе Query Processing Layer веб-версии нашей статьи для VLDB 2024.

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

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

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

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

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

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

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

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

• Что будет сортироваться: числа, кортежи, строки или структуры?
• Данные находятся в оперативной памяти?
• Необходима ли стабильная сортировка?
• Нужно ли отсортировать все данные или будет достаточно частичной сортировки?

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

🤿 Более подробно об этом в разделе Holistic Performance Optimization веб-версии нашей статьи для VLDB 2024.

Статья для VLDB 2024

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

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

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