MARKLOGIC SERVER

Every fragment acts as its own self-contained unit. It's the unit of indexing. A term list
doesn't truly reference document IDs; it references fragment IDs. The filtering and
retrieval process doesn't actually load documents; it loads fragments.
There's actually very little difference between fragmenting a book at the chapter level
and just splitting each chapter element into its own document as part of the load. That's
why people generally avoid fragmentation and just keep each document as its own
singular fragment. It's a slightly easier mental model.
In fact, if you see "fragment" in MarkLogic literature (including this book), you can
substitute "document" and the statement will be correct for any databases where no
fragmentation is enabled.
There's one noticeable difference between a fragmented document and a document
split into individual documents: a query pulling data from two fragments residing in
the same document can perform slightly more efficiently than a query pulling data
from two documents. See the documentation for the cts:document-fragmentquery()
query construct for more details. Even with this advantage, fragmentation
isn't something you should enable unless you're sure you need it.
ESTIMATE AND COUNT
You'll find that you really understand MarkLogic's indexing and fragmentation system
when you understand the difference between the xdmp:estimate() and fn:count()
functions, so let's look at them here. Both take an expression and return the number of
items matching that expression.
The xdmp:estimate() call estimates the number of items using nothing but indexes.
That's why it's so fast. It resolves the given expression using indexes and returns how
many fragments the indexes see as satisfying all of the term list constraints.
The fn:count() returns a number of items based on the actual number of document
fragments. This involves indexes and also filtering of the fragments to see which ones
truly match the expression and how many times it matches per document. That filtering
takes time (due mostly to disk I/O), which is why it's not always fast, even if it's
always accurate.
It's interesting to note that the xdmp:estimate() call can return results both higher
and lower than, as well as identical to, those of fn:count()—depending on the query,
data schema, and index options. The estimate results are higher when the index system
returns fragments that would be filtered away. For example, a case-sensitive search
performed without benefit of a case-sensitive index will likely have some candidate
25