Please use the form below to provide your feedback. Because your feedback is valuable to us, the information you submit in this form is recorded in our issue tracking system (JIRA), which is publicly available. You can track the status of your feedback using the ticket number displayed in the dialog once you submit the form.

FTS Architecture

    +
    The FTS Architecture is explained in the form of diagrams. Each diagram is co-located with its textual description.

    Search Service Architecture

    The Search Service provides extensive capabilities for natural-language querying. These include:

    • Language-aware searching; allowing users to search for, say, the word traveling, and additionally obtain results for travel and traveler.

    • Scoring determines the relevancy of the documents. Scoring helps order the results. The size of the result set is controlled independently.

    • Fast indexes, which support a wide range of possible text-searches.

    The indexes that the Search Service creates and uses are entirely separate from and different from those of the Index Service.

    However, if the Index and Query Services are also deployed on the cluster, the facilities of the Search Service can be called on by means of the N1QL language — which provides the principal interface to the Query and Index Services. See Accessing the Search Service with N1QL, below.

    The Search Service depends on the Data Service, as follows:

    searchServiceArchitecture2

    It shows the following:

    • The Data Service uses the DCP protocol to stream data-mutations as batches, from the producer to multiple consumers (vBuckets), instantiated across the search nodes.

    • When a search index is created by means of the Search Service, search-index data-handling for the vBuckets is divided equally among the established search-index partitions.

    For example, when the number of vBuckets is 1024, and the number of search-index partitions chosen is 6, each search-index partition holds data for ~171 vBuckets

    All available Search Service nodes in the cluster are individually searchable. When one particular Search Service node is chosen for a search request, it assumes the role of coordinator; and is thereby responsible for applying the search request to the other Search Service nodes and for gathering and returning results. The following illustration depicts this scatter-gather execution of a search request:

    searchServiceOperation

    This illustration shows how:

    • The application makes a search request to a specific Search Service node (here, Node 1). This node assumes the role of coordinator.

    • The coordinator scatters the search request to all other search-index partitions (here, Node 2 and Node 3) in the cluster.

    For extensive information on how to use the service, see Full Text Search: Fundamentals.