Индексы

Типы индексов

DuckDB имеет два встроенных типа индексов. Индексы также могут быть определены с помощью расширений.

Индекс Min-Max (Zonemap)

Индекс min-max (также известный как zonemap и индекс блочных диапазонов) автоматически создаётся для столбцов всех общих типов данных.

Дерево адаптивного радикса (ART)

Дерево адаптивного радикса (ART) в основном используется для обеспечения ограничений первичного ключа и ускорения запросов точечных и очень высокоселективных (т.е., < 0.1%) запросов. Индексы ART автоматически создаются для столбцов с ограничением UNIQUE или PRIMARY KEY и могут быть определены с помощью CREATE INDEX.

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

Индексы, определённые расширениями

Начиная с версии 1.1.0, DuckDB поддерживает R-деревья для пространственной индексации через расширение spatial.

Сохранение

Индексы min-max и индексы ART сохраняются на диске.

CREATE INDEX и DROP INDEX

Для создания индекса используйте CREATE INDEX оператор. Для удаления индекса используйте DROP INDEX оператор.

Ограничения индексов ART

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

Как ожидалось, индексы оказывают сильное влияние на производительность, замедляя загрузку и обновления, но ускоряя определённые запросы. Подробности см. в Руководстве по производительности.

Обновления превращаются в удаления и вставки

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

Чрезмерная проверка уникальных ограничений

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

CREATE TABLE students (id INTEGER, name VARCHAR);
INSERT INTO students VALUES (1, 'John Doe');
CREATE UNIQUE INDEX students_id ON students (id);

BEGIN; -- start transaction
DELETE FROM students WHERE id = 1;
INSERT INTO students VALUES (1, 'Jane Doe');

Последнее утверждение завершается с ошибкой:

Constraint Error: Duplicate key "id: 1" violates unique constraint. If this is an unexpected constraint violation please double check with the known index limitations section in our documentation (https://duckdb.org/docs/sql/indexes).

Это, в сочетании с тем, что обновления превращаются в удаления и вставки в рамках одной транзакции, означает, что обновление строк в присутствии ограничений уникальности или первичного ключа часто может привести к неожиданным нарушениям уникальных ограничений. Например, в следующем запросе SET id = 1 приводит к появлению Constraint Error.

CREATE TABLE students (id INTEGER PRIMARY KEY, name VARCHAR);
INSERT INTO students VALUES (1, 'John Doe');

UPDATE students SET id = 1 WHERE id = 1;

Constraint Error: Duplicate key "id: 1" violates primary key constraint.
If this is an unexpected constraint violation please double check with the known index limitations section in our documentation (https://duckdb.org/docs/sql/indexes).

В настоящее время это ожидаемое ограничение DuckDB — хотя мы стремимся решить эту проблему в будущем.