MARKLOGIC SERVER

INDEXING VALUES
Now what if we want to search for element values? Let's imagine that I ask
you for books published in a certain year. In XPath, that can be expressed as /
book[metadata/pubyear = 2016]. How do we resolve this efficiently?
Thinking back to the paper-based approach, what you want to do is maintain a term
list for each XML element value (or JSON property value). In other words, you can
track a term list for documents having a equal to 2016, as well as any
other element name with any other value you find during indexing. Then, for any
query asking for an element with a particular value, you can immediately resolve which
documents have it directly from indexes. Intersect that value index with the parent-child
structural indexes discussed above, and you've used several small indexes in cooperation
to match a larger query. It works even when you don't know the schema or query in
advance. This is how you build a database using the heart of a search engine.
Can an element-value index be stored efficiently? Yes, thanks to hashing. Instead of
storing the full element name and value, you can hash the element name and value
down to a succinct integer and use that as the term list lookup key. Then no matter how
long the element name and value, it's actually a small entry in the index. MarkLogic
uses hashes behind the scenes to store all term list keys, element-value or otherwise, for
the sake of efficiency. The element-value index has proven to be so efficient and useful
that it's always and automatically enabled within MarkLogic.
In the above example, 2016 is queried as an integer. Does MarkLogic actually store
the value as an integer? By default, no—it's stored as the textual representation of the
integer value, the same as it appeared in the document, and the above query executes
the same as if 2016 were surrounded by string quotes. Often this type of fuzziness is
sufficient. For cases where data type encoding matters, it's possible to use a range index,
which is discussed later.
17