About Geographically Distributed Indexing
With GDI, a user makes a single query request in the search interface of the local Coveo instance. The query is distributed to the remote indexes participating in the federation. The local Coveo instance receives, merges, and ranks results from local and remote indexes before returning them to the user.
The Coveo scalability model supports two GDI configurations that are transparent to end-users.
-
Query federated to the remote index
-
In this configuration, the local Coveo instance sends federated queries to the remote indexes over the WAN (see Setting up Geographically Distributed Indexing).
This configuration is very simple to set up and has negligible impact on the WAN bandwidth. The query performance may however be affected by the time required for the round trip to the remote Coveo instance.
Example: Users working in the Palo Alto and Chicago offices must be able to search content from the Coveo instance in the other office. In the Palo Alto office, you configure the Coveo instance to accept queries from the Coveo instance in the Chicago office. In the Chicago office, you configure the Coveo instance to accept queries from the Coveo instance in the Palo Alto office.
-
Query federated to a local mirror of a remote index
-
In this configuration, you locally install a Coveo Mirror server of the remote index. You configure the remote Coveo instance to synchronize its index with this Mirror server over the WAN. The local Coveo instance sends federated queries to the local mirror of the remote index (see Setting up Geographically Distributed Indexing Using a Mirror).
Example: In the Palo Alto office, you deploy a Coveo Mirror server of the Chicago index office. You configure the Chicago Coveo instance to synchronize its index with the Palo Alto mirror server. You configure the Palo Alto Coveo instance to use the mirror server as the Chicago remote index. In the Chicago office, you can do the same thing for the Palo Alto office.
Note: When connecting two indexes in a GDI configuration, it is a good practice to keep the index field configuration as similar as possible in the two indexes to prevent problems.
Example: The @systemstatus field is present or is configured as a facet field only in one of the indexes. When
you create a facet with this field in a Coveo .NET Front-End search interface, you
can get an error similar to the following one:
"Call returned SOAP fault class CES::SearchServerException: class CES::SearchServerException: class Merlin::KIEException: class Merlin::KIEInvalidFacetField: The field is not a facet field or is a field that cannot be optimized (@systemstatus)."