Ошибка расширенного кэша дерева - PullRequest
0 голосов
/ 26 июня 2018

для следующего кода я получаю полный кэш расширенного дерева:

xquery version "1.0-ml";
let $result :=
  <root>{
    cts:search(
      fn:collection("metadata-search")/metadata,
      cts:and-query((   
          cts:element-value-query(xs:QName('AssetID'), "*")
      ))
    )/assetIdentifiers/assetIdentifier/AssetID


  }</root>
let $path := "D:\Output\input.xml"
return 
  xdmp:save($path, $result,
            <options xmlns="xdmp:save">
              <method>xml</method>
            </options>
  )

но если тот же код, который я запускал в режиме итерации, он работал нормально:

xquery version "1.0-ml";
let $result :=
  <root>{
    for $data in cts:search(
      fn:collection("metadata-search")/metadata,
      cts:and-query((   
         cts:element-value-query(xs:QName('AssetID'), "*")
      ))
    )
    return $data/assetIdentifiers/assetIdentifier/AssetID
  }</root>
let $path := "D:\Output\input.xml"
return 
  xdmp:save($path, $result,
            <options xmlns="xdmp:save">
              <method>xml</method>
            </options>
  )

В базе данных 450000 ресурсов, и для ее запуска потребовалось 10 минут, мне было интересно, почему другая конструкция кода работает нормально, а не первая? Любая идея, пожалуйста, дайте мне знать подробно с контекстом этого кода?

1 Ответ

0 голосов
/ 26 июня 2018

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

Обратите внимание, что он все равно не будет хорошо масштабироваться. Скорее всего, вам лучше пакетировать результаты поиска, индивидуально сохранять партии и агрегировать в общий XML вне MarkLogic, если это действительно необходимо. Такие инструменты, как Corb2 , и библиотеки, такие как DMSDK , могут быть здесь очень полезны, делая тяжелую работу за вас.

НТН!

...