cts: запрос элемента против производительности cts: path-range-query

Question

Мы разрабатываем корпоративное приложение, которое хранит огромное количество данных. В нашем приложении мы заставили пользователя создать несколько индексов диапазона пути, чтобы сделать поиск быстрее.

Ранее мы использовали преимущества индексов диапазона путей для ускорения поиска с использованием cts: path-range-query () , но теперь я обнаружил, что тот же результат я могу получить с помощью cts : element-query () без создания индексов диапазона пути.

Например -

1. Использование cts: path-range-query () -> Здесь мне нужно создать индекс диапазона пути для / tXML / Message / INVENTORY / ASNId

   xquery version "1.0-ml"; cts:uris('', (), cts:and-query((cts:collection-query("integration"), cts:path-range-query("/tXML/Message/INVENTORY/ASNId", "=", "10121600"))))

2. Использование cts: element- query () -> Здесь мне не нужно создавать указатель диапазона пути.

   xquery version "1.0-ml"; cts:uris('', (), cts:and-query((cts:collection-query("integration"), cts:element-query(xs:QName("tXML"),cts:element-query(xs:QName("Message"), cts:element-query(xs:QName("INVENTORY"), cts:element-value-query(xs:QName("ASNId"), "10121600")))))))

Мои вопросы:

1. Если я получаю тот же результат, что и cts: path-range-query () с использованием cts: element-query (), тогда зачем мне заставлять пользователя создавать индексы диапазона пути?

2. какой запрос подходит для огромного набора данных?. ( cts: element-query () или cts: path-range-query () )

Пожалуйста, помогите мне найти ответы на эти два вопроса.

Answer 1

Ответ не совсем прямой, то есть результаты могут отличаться в зависимости от данных и объема.

Пара замечаний:

• Ваши запросы не семантически то же. Запросы элементов проверяют предков, в то время как в пути вы можете быть более строгими и требовать указания c родителей, поэтому прямые отношения родитель-потомок, а не отношения предок-потомок
• Запросы диапазона разрешаются для индексов диапазона с помощью предопределенные параметры сортировки и всегда против целого («точного») значения. Однако запросы значений разрешаются по универсальному индексу. Точнее, по отношению к индексу с незаполненными токенами. Если ваше значение состоит из нескольких токенов, для этого потребуются включенные позиции или отфильтрованные поиски на точность. Однако значение в вашем примере состоит только из одного токена.
• Индексы диапазона пути обходятся дорого во время загрузки, немного больше, чем индексы диапазона элемента. Индексы диапазона также занимают дополнительную память. Запросы к элементам и запросы к значениям элементов занимают немного больше времени для поиска во время поиска. Однако вам может потребоваться большой набор тестов, чтобы заметить существенные различия.
• И последнее, но не менее важное: вы не можете выполнять запросы неравенства или искать значения для фасетов и тому подобное без индексов диапазона.

НТН!