Комментарии 2
но при его выполнении будет просканирован каждый тег в базе, что является очень ресурсоемкой задачей
А использование предварительного индексирования разве не может снизить ресурсоемкость поиска на порядки?
Вы правы. Видимо я немного не так выразился. Дело все в том, что это очень сильно зависит от структуры данных (документов). Об индексах напишу чуть позже. Чтобы ответить на Ваш вопрос расскажу вот это:
По индексам ML получает документы в которых содержится тег (ns1:horse). Эта процедура довольно сложная и запутанная. Результатом выборки по индексам является набор документов которые ML должен открыть и выбрать все теги (ns1:horse), т.к. вы указываете в XPath конкретный тег который должен стать результатом. Засада здесь в том, что если документ содержит много тегов то эта процедура выполняется долго. Если же указан конкретный путь до тега, то ML пройдет только по этому пути. Понижение производительности проявится в случае если XML имеет много уровней вложенности и содержит большое количество тегов на каждом уровне.
Описанные выражения можно использовать при хорошо спроектированных данных и правильном использовании средств ML повышающих производительность. В таком случае производительность этих выражений будет одинаковой. В некоторых случаях выражение (//ns1:horse) будет работать быстрее. Но! Не стоит использовать потенциально проблемные выражения.
Кстати, в ML существует механизм позволяющий избавиться от описанных проблем. Суть его заключается в том, что документ разбивается на фрагменты по тегам и вот этот механизм уже должен быть настроен разработчиком, должны быть указаны корневые теги фрагментов. Но об этом позже и подробнее :).
По индексам ML получает документы в которых содержится тег (ns1:horse). Эта процедура довольно сложная и запутанная. Результатом выборки по индексам является набор документов которые ML должен открыть и выбрать все теги (ns1:horse), т.к. вы указываете в XPath конкретный тег который должен стать результатом. Засада здесь в том, что если документ содержит много тегов то эта процедура выполняется долго. Если же указан конкретный путь до тега, то ML пройдет только по этому пути. Понижение производительности проявится в случае если XML имеет много уровней вложенности и содержит большое количество тегов на каждом уровне.
Описанные выражения можно использовать при хорошо спроектированных данных и правильном использовании средств ML повышающих производительность. В таком случае производительность этих выражений будет одинаковой. В некоторых случаях выражение (//ns1:horse) будет работать быстрее. Но! Не стоит использовать потенциально проблемные выражения.
Кстати, в ML существует механизм позволяющий избавиться от описанных проблем. Суть его заключается в том, что документ разбивается на фрагменты по тегам и вот этот механизм уже должен быть настроен разработчиком, должны быть указаны корневые теги фрагментов. Но об этом позже и подробнее :).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Данные в MarkLogic Server [Part1]