Почему ClickHouse такой быстрый?
Многие другие факторы способствуют производительности базы данных помимо ее ориентации на данные. В следующем разделе мы подробнее объясним, что делает ClickHouse таким быстрым, особенно по сравнению с другими колоночными базами данных.
С архитектурной точки зрения базы данных состоят (по крайней мере) из уровня хранения и уровня обработки запросов. В то время как уровень хранения отвечает за сохранение, загрузку и поддержку данных таблицы, уровень обработки запросов выполняет запросы пользователей. По сравнению с другими базами данных ClickHouse предоставляет инновации в обоих уровнях, которые обеспечивают чрезвычайно быстрые вставки и запросы Select.
Уровень хранения: Параллельные вставки изолированы друг от друга
В ClickHouse каждая таблица состоит из нескольких "частей таблицы". Часть создается каждый раз, когда пользователь вставляет данные в таблицу (оператор INSERT). Запрос всегда выполняется по всем частям таблицы, которые существуют на момент начала выполнения запроса.
Чтобы избежать накопления слишком большого количества частей, ClickHouse выполняет объединение в фоновом режиме, которое постоянно объединяет несколько меньших частей в одну большую часть.
Этот подход имеет несколько преимуществ: Вся обработка данных может быть перенесена на фоновое объединение частей, что делает запись данных легкой и максимально эффективной. Индивидуальные вставки являются "локальными" в том смысле, что им не нужно обновлять глобальные, т.е. табличные структуры данных. В результате несколько одновременных вставок не требуют взаимной синхронизации или синхронизации с существующими данными таблицы, и, таким образом, вставки могут выполняться почти на скорости I/O диска.
раздел оптимизации общей производительности в статье VLDB.
🤿 Углубитесь в это в разделе Формат на диске веб-версии нашей статьи VLDB 2024.
Уровень хранения: Параллельные вставки и выборки изолированы
Вставки полностью изолированы от запросов SELECT, а объединение вставленных частей данных происходит в фоновом режиме без влияния на параллельные запросы.
🤿 Углубитесь в это в разделе Уровень хранения веб-версии нашей статьи VLDB 2024.
Уровень хранения: Вычисление времени объединения
В отличие от других баз данных, ClickHouse сохраняет записи данных легкими и эффективными, выполняя все дополнительные преобразования данных во время фонового объединения. Примеры включают:
-
Объединение с заменой, которое сохраняет только последнюю версию строки во входных частях иdiscardall другие версии строки. Объединение с заменой можно рассматривать как операцию очистки во время объединения.
-
Объединения с агрегацией, которые комбинируют промежуточные состояния агрегации во входной части в новое состояние агрегации. Хотя это может показаться трудным для понимания, на самом деле это просто реализует инкрементальную агрегацию.
-
Объединения 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+ предварительно скомпилированных вариантов хеш-таблицы на основе особенностей запроса и данных.
Алгоритмы. То же самое касается алгоритмов. Например, в сортировке вам нужно учесть:
- Что будет сортироваться: числа, кортежи, строки или структуры?
- Данные находятся в оперативной памяти?
- Требуется ли стабильная сортировка?
- Нужно ли сортировать все данные, или достаточной будет частичная сортировка?
Алгоритмы, которые полагаются на характеристики данных, часто работают лучше, чем их универсальные аналоги. Если характеристики данных заранее не известны, система может попробовать несколько реализаций и выбрать ту, которая лучше всего работает во время выполнения. Для примера смотрите статью о том, как реализовано декомпрессирование LZ4 в ClickHouse.
🤿 Углубитесь в это в разделе Оптимизация общей производительности веб-версии нашей статьи VLDB 2024.
Статья VLDB 2024
В августе 2024 года наша первая научная статья была принята и опубликована на VLDB. VLDB - это международная конференция по очень большим базам данных и широко признается одной из ведущих конференций в области управления данными. Среди сотен заявок VLDB обычно имеет коэффициент принятия около 20%.
Вы можете прочитать PDF статьи или нашу веб-версию ее, которая содержит краткое описание самых интересных архитектурных и системных компонентов ClickHouse, которые делают его таким быстрым.
Алексей Миловидов, наш технический директор и создатель ClickHouse, представил статью (слайды здесь), после чего последовал сеанс вопросов и ответов (который быстро вышел за пределы времени!). Вы можете посмотреть записанную презентацию здесь: