Индексирование

DuckDB имеет два типа индексов: zonemaps и ART-индексы.

Zonemaps

DuckDB автоматически создаёт zonemaps (также известные как индексы min-max) для столбцов всех общих типов данных. Эти индексы используются для проталкивания предиката в операторы сканирования и вычисления агрегаций. Это означает, что если используется условие фильтрации (например, WHERE column1 = 123), DuckDB может пропустить любые группы строк, минимально-максимальный диапазон которых не содержит это значение фильтра (например, блок с диапазоном min-max от 1000 до 2000 будет пропущен при сравнении с = 123 или < 400).

Влияние упорядочивания на zonemaps

Чем упорядоченнее данные в столбце, тем полезнее будут индексы zonemap. Например, в худшем случае столбец может содержать случайное число на каждой строке. DuckDB вряд ли сможет пропустить какие-либо группы строк. Лучший случай упорядоченных данных обычно возникает со столбцами DATETIME. Если конкретные столбцы будут запрошены с селективными фильтрами, лучше всего предварительно упорядочить данные по этим столбцам при их вставке. Даже неполное упорядочение всё ещё будет полезным.

Микробенчмарк: Влияние упорядочивания

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

Результаты показывают, что простое сохранение порядка столбца позволяет улучшить сжатие, что приводит к уменьшению размера хранения в 2,5 раза. Это также позволяет ускорить вычисления в 1,5 раза.

Упорядоченные целые числа

Другой практический способ использовать упорядочение — использовать тип INTEGER с автоматическими инкрементами вместо UUID для столбцов, которые будут запрошены с помощью селективных фильтров. UUID скорее всего будут вставлены в случайном порядке, поэтому для поиска определенного значения UUID в таблице потребуется просканировать многие группы строк, в то время как упорядоченный столбец INTEGER позволит пропустить все группы строк, кроме той, которая содержит значение.

ART-индексы

DuckDB позволяет определять индексы адаптивных радикс-деревьев (ART) двумя способами. Во-первых, такой индекс создаётся неявно для столбцов с PRIMARY KEY, FOREIGN KEY, и UNIQUE ограничениями. Во-вторых, явное выполнение оператора CREATE INDEX создаёт ART-индекс для целевого столбца (столбцов).

Компромиссы при наличии ART-индекса в столбце следующие:

1. Он позволяет эффективно проверять ограничения при изменениях (вставках, обновлениях и удалениях) для изменений, не являющихся объёмными.
2. Наличие ART-индекса замедляет изменения в соответствующих столбцах по сравнению с производительностью без индексов. Это связано с обслуживанием индекса для этих операций.

Что касается производительности запросов, ART-индекс оказывает следующие воздействия:

1. Он ускоряет точечные запросы и другие высокоселективные запросы, использующие индексированные столбец(ы), где условие фильтрации возвращает приблизительно 0,1% или меньше всех строк. В случае сомнений используйте EXPLAIN, чтобы убедиться, что ваш план запроса использует сканирование по индексу.
2. ART-индекс не влияет на производительность запросов JOIN, агрегации и сортировки.

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

Рекомендации по наилучшей практике Мы рекомендуем следовать этим рекомендациям:

• Используйте только первичные ключи, внешние ключи или уникальные ограничения, если это необходимо для обеспечения ограничений на ваши данные.
• Не определяйте явные индексы, если у вас нет высокоселективных запросов.
• Если вы определяете ART-индекс, сделайте это после массовой загрузки данных в таблицу. Добавление индекса до загрузки, явным образом или через первичные/внешние ключи, ухудшает производительность загрузки.