Использование индекса ArangoDB с краевыми коллекциями

Задача: самый быстрый способ обновить многие атрибуты ребер. По соображениям производительности я игнорирую методы графа и работаю с коллекцией непосредственно для фильтрации.

АрангоДБ 2.8b3

Запрос [Предложение - сбор краев]:

FOR O In Offer
FILTER O._from == @from and O._to == @to and O.expired > DATE_TIMESTAMP(@newoffertime)
UPDATE O WITH { expired: @newoffertime } IN Offer
RETURN { _key: OLD._key, prices_hash: OLD.prices_hash }

У меня есть системный индекс по _to, _from и индекс диапазона по истечению

Запросить объяснение шоу

7   edge   Offer        false    false        49.51 %   [ `_from`, `_to` ]   O.`_to` == "Product/1023058135528"

Системный индекс используется для фильтрации только части записей (_to), а не для обеих (_from, _to), индекс с истекшим сроком действия также не используется. Пожалуйста, объясните мне причины такого поведения, и есть возможность указать подсказку индексов, которые будут использоваться для кратчайшего пути, если я точно знаю при планировании модели данных?


performance indexing aql arangodb
person Felix Berth    schedule 01.01.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Для условий фильтрации в сочетании с логическим И, как в вашем запросе, оптимизатор запросов ArangoDB выберет один индекс. По этой причине он не выбрал индекс кромки и индекс пропуска одновременно.

Он будет выбирать между индексом пропуска на expired и индексом края на [ "_from", "_to" ], и выберет тот, для которого он определяет более низкую стоимость, которая измеряется оценками селективности индекса. Как видно из вывода объяснения, похоже, что он выбрал индекс края на _to.

Индекс края внутренне состоит из двух отдельных хэш-индексов, одного для атрибута _from, а другого для атрибута _to, поэтому он обеспечивает быстрый доступ через атрибуты _from и _to. Однако это не комбинированный индекс для [ "_from", "_to" ], поэтому он не поддерживает запросы, которые одновременно запрашивают _from и _to. Он должен выбрать один из внутренних хеш-индексов и, похоже, выбрал тот, который находится на _to в этом запросе. Решение снова основывается на средней избирательности индекса.

Невозможно предоставить оптимизатору подсказку об использовании индекса - кроме этого, он не сможет использовать два индекса одновременно для этого конкретного запроса.

Глядя на оценку селективности в выходных данных объяснения, кажется, что индекс ребер не очень избирательный, что означает, что будет много ребер с одинаковыми значениями _to. Поскольку оптимизатор также должен был принять во внимание индекс на _from, я бы предположил, что индекс еще менее избирательный, и что каждый из этих индексов поможет пропустить не более 50% краев, что не очень много. Если это действительно так, то запрос по-прежнему будет извлекать (и выполнять последующую фильтрацию) множество документов, что объясняет потенциальную медлительность.

В настоящий момент атрибуты _from и _to автоматически индексируются в всегда присутствующем индексе края коллекции краев, и они не могут использоваться в дополнительных, определяемых пользователем индексах. Это функция, которую мы хотели бы добавить в будущую версию, потому что с _from и _to, доступными для определяемых пользователем индексов, можно было бы создать комбинированный (отсортированный) индекс на [ "_from", "_to", "expired" ], который потенциально был бы намного более избирательным, чем любой из три отдельных индекса с одним атрибутом.

person stj    schedule 04.01.2016