MARKLOGIC SERVER

subchild. What would you do? With the simple element term list from above you can
find documents having , , and elements. That's good,
but it doesn't respect the required hierarchical relationship. It's like a phrase query that
looks for words without concern for placement.
MarkLogic uses a unique parent-child index to track element hierarchies. It's much like
a fast phrase searches index except that instead of using adjoining words as the term key
it uses parent-child names. There's a term list tracking documents that have a book/
metadata relationship (that is, a as a parent of a ) and another
for metadata/title. There's even one tracking which documents have any particular
root element. Intersecting these three lists produces an even better set of candidate
documents. Now you can see how the XPath /a/b/c can be resolved very much like
the phrase "a b c".
The parent-child index lets you search against an XPath even when you don't know the
path in advance. The index is so useful that it's one MarkLogic always maintains; there's
no configuration option to turn it off.
Note that even with the parent-child index, there's still the small potential for
documents to be in the candidate set that aren't an actual match. Knowing that
somewhere inside an XML document there's a parent of and
a parent of doesn't mean it's the same between
them. That's where filtering comes in. MarkLogic confirms each of the results by
looking inside the document before the programmer sees them. While the document is
open, MarkLogic also extracts any nodes that match the query.
Remember that the goal of index resolution is to make the candidate set so small and
accurate that very little filtering is needed.
Doc 1
Parent-Child Index
Term Doc
a/b
a/e
1
1
b/c 1
b/d 1
Figure 3: MarkLogic indexes the parent-child relationships of XML elements to enable search based
on document structure. (It does the same for the properties in JSON documents.)
16