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.

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.

      Under the hood, the search service has several key elements as shown in the architecture diagram below:

      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.

      How the search service operates is illustrated in the following diagram:

      searchServiceOperation

      The diagram shows the following:

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

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

      Once all the returned data is gathered, the coordinator applies filters appropriately and returns the final results to the user.

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