MARKLOGIC SERVER

LIFECYCLE OF A QUERY IN A CLUSTER
Earlier we covered the lifecycle of a query. Let's do that again but with an eye toward
how the E-nodes and D-nodes communicate and where the caches fit in.
Let's assume that we're running the same cts:search() as before—the one that
liked cats and puppy dogs but didn't like fish. In order to gather term lists, the E-node
pushes a representation of the search expression to each forest in the database in
parallel. Each forest on a D-node returns an iterator to its score-sorted results. All the
term list selection and intersection happen on the D-node. Locks would happen on the
D-node side as well, but since this is a read-only query, it runs lock-free.
The E-node selects from the iterators holding the highest scores and pulls from them
to locate the most relevant results from across the database. Over the wire, it receives
fragment IDs along with score data. When the E-node retrieves the actual fragment
associated with the fragment ID, it looks first to its own Expanded Tree Cache. If it
can't find it, it requests the fragment from the D-node from which the fragment ID
came. The D-node looks in its own Compressed Tree Cache for the fragment, and if
it's not in that cache either, it pulls it off disk.
At this point, the E-node may filter the fragment. It looks at its tree structure and
checks if it truly matches the search constraints. Only if it survives the filtering does it
proceed to the return clause and become a generated result. If the query is running as
unfiltered, no checking occurs.
52