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