Внутренняя ошибка сервера из-за большой продолжительности выполнения XQuery (MarkLogic)

ProgramBox

Внутренняя ошибка сервера из-за большой продолжительности выполнения XQuery (MarkLogic)

Post author:admin
Запись опубликована:2 мая, 2023
Post category:Вопросы по программированию

#java #marklogic

Вопрос:

В настоящее время я выполняю некоторые запросы, используя Java API, предоставляемый MarkLogic. Я установил его, добавив необходимые зависимости в свою библиотеку. Соединение установлено с помощью

 DatabaseClient client = DatabaseClientFactory.newClient("localhost", 8000, secContext, ConnectionType.DIRECT);

Отсюда некоторые XQueries выполняются с использованием кода, показанного ниже

 ServerEvaluationCall evl = client.newServerEval().xquery(query);
EvalResultIterator evr = evl.eval();
while(evr.hasNext()){
//Do something with the results
}

Однако обработка некоторых запросов занимает много времени, вызывая внутреннюю ошибку.Итак, кроме сокращения требуемого времени запроса, мне интересно, есть ли способ преодолеть это? Например, увеличение срока подключения.

====Обновление===

Используемый запрос

 xquery version "1.0-ml";

let $query-opts := /comments[fn:matches(text,".*generation.*")]

return(
$query-opts, fn:count($query-opts), xdmp:elapsed-time()
)

Я знаю, что используемое регулярное выражение может быть легко заменено word-query. Но для этого экземпляра я хотел бы просто использовать регулярное выражение для поиска.

Пример данных

 <comments>
<date_commented>1998-01-14T04:32:30</date_commented>
<text>iCloud sync settings are not supposed to change after an iOS update. In the case of iOS 10.3 this was due to a bug.</text>
<uri>/comment/000000001415898</uri>
</comments>

1. У вас есть проблемы как с Select, так и с Update? или вы можете объяснить, какие запросы занимают больше времени?

2. Это очень простой запрос, который проверяет наличие определенного слова с помощью word-query и возвращает документ, оттуда я использую fn:count() для определения количества документов. Но он считает миллионы документов, что отнимает много времени. @Ramachandra Reddy

3. Вместо fn:count() вы могли бы использовать xdmp:estimate , который не требует загрузки / синтаксического анализа документов в память и должен быть намного быстрее. docs.marklogic.com/xdmp:estimate

4. Да, я думал об этом. Но проблема в xdmp: подсчет оценок на основе индекса. Итак, если, скажем, я использую путь / данные [некоторое условие], он все равно вернет мне количество всех записей документов с путем / данными, даже если возвращаемые результаты — это только 1 документ из-за примененного условия. @Вагнер Майкл

5. Да, это правда. Можете ли вы опубликовать свой запрос данные? Вы могли бы попробовать преобразовать свои данные, чтобы у них не было нескольких узлов на фрагменты. Таким образом, путь / данные уникальны для каждого фрагмента.

Ответ №1:

На основе предоставленных вами данных я бы использовал xdmp:estimate и запрос cts.

 xdmp:estimate(cts:search(doc(), cts:and-query((
  cts:directory-query('/comment/'),
  cts:element-word-query(xs:QName("text"), "generation")
))))

Это приведет к поиску элемента, /comments/ содержащего слово text , во всех документах в вашем generation каталоге. Как вы уже знаете, при этом будут использоваться только индексы и не потребуется загрузка / синтаксический анализ документов.

Это также не приведет к обнаружению ложных срабатываний, поскольку в документе / фрагменте имеется только один text элемент (если показанные вами данные верны).

1. Одно примечание к этому хорошему ответу: вместо увеличения времени ожидания (которое может снова начать давать сбой, если размер базы данных увеличивается), типичной стратегией является перелистывание результатов в нескольких запросах.

2. Спасибо за ваш ответ. Но я хотел бы задать еще один вопрос напоследок. Основываясь на ваших кодах, я попытался заменить «cts: element ….)» на «/comments[fn: matches(text,».*generation.*»)]» и время, затраченное внезапно, значительно увеличивается. Есть ли для этого определенные основания? Я попытался запустить «/comments [fn: matches(text,».*generation.*»)]» сам по себе, и это завершилось менее чем за секунду. @Вагнер Майкл

3. Виноват поиск по шаблону. В зависимости от вашего варианта использования вы можете посмотреть на варианты для lexicon-expand , lexicon-expansion-limit и limit-check ( docs.marklogic.com/cts:element-word-query ) и / или подстановочных индексов ( docs.marklogic.com/guide/search-dev/wildcard )

4. @WhiteSolstice Выражение XPath загружает каждый фрагмент документа, содержащий comments элемент. Затем на втором этапе фильтрации он отфильтровывает все фрагменты, не содержащие слово «генерация» с помощью регулярного выражения. Это сильно снижает производительность. Чтобы лучше понять это, сравните оба запроса с использованием xdmp:plan(...) . Я не уверен, почему только XPath работает намного быстрее. Может быть потому, что запрос / фрагменты уже кэшированы.