Starting with version 6.1.0, the MDEX Engine processes partial updates concurrently with processing query requests.
During continuous query processing, the MDEX Engine Dgraph port remains open for both query processing and partial updates processing. (In previous releases, when processing partial updates, the MDEX Engine closed its port temporarily.)
Continuous query is enabled starting with the MDEX Engine version 6.1.0 for all types of queries to the Engine, including navigation, record and aggregated record queries, queries with text search, queries that contain filters (EQL, range and record filters), queries containing Web services and XQuery, and all other types of queries.
Since the MDEX Engine continues to process all incoming queries while partial updates are running, queries are processed against either the pre-update or post-update state of the index data, depending on when they arrive. Pre-update and post-update states refer to the states before and after a partial update was applied. The MDEX Engine never processes queries against the data that is in the state of being updated through a partial update.
With continuous query, the MDEX Engine maintains its query processing performance levels, including low query latency and partial updates latency.
A few administrative queries are processed differently; for details see the section "Continuous query processing and administrative queries".
In previous releases, you could specify the
offline=[true|false] option as part of the
admin?op=update query. This parameter has been removed
and does not exist in the MDEX Engine 6.1.0, because the Engine no longer goes
offline while processing updates. If you issue an
admin?op=update&offline=true|false, the MDEX Engine
ignores this request, issues a warning and continues to process an update while
keeping its port open.
In addition, in previous releases, to ensure adequate performance after
an update, after a partial update was complete and before opening its port to
accept new queries, the MDEX Engine ran warming replay queries by default.
Starting with version 6.1.0, the MDEX Engine no longer replays warming queries
after updates since its port never closes during updates processing, and the
warmupseconds option of the
admin?op=update is ignored by the MDEX Engine. The
Dgraph issues a warning if it is issued and continues its processing.
You can issue administrative queries to the MDEX Engine concurrently with running updates, without any interruptions caused by partial updates processing, except for the following administrative and configuration queries that are processed differently.
admin?op=exit and
admin?op=restart queries cause the MDEX Engine to close
its Dgraph port for accepting future queries. Next, the MDEX Engine processes
all previously received queries and shuts down (or restarts, depending on which
of these two commands is issued).
config?op=update and
admin?op=reload-services operations cause the MDEX
Engine to drain all existing preceding queries, temporarily stop processing
other queries and begin to process
config?op=update and
admin?op=reload-services. After it finishes processing
these operations, the MDEX Engine resumes processing queries that queued up
temporarily behind these requests.
Only one
config?op=update operation can be processed at a time.
Note
config?op=update and
admin?op=reload-services can be time-consuming
operations. This depends on the number of configuration files the MDEX Engine
has to process for an update (during
config?op=update), or the number of XQuery modules
that you have created and that have to be compiled (during
admin?op=reload-services).
You can issue all other administrative queries to the MDEX Engine concurrently with updates, without any interruptions caused by partial updates processing.
