MongoDB Search - Full-Text and Vector Search | ApsaraDB for MongoDB - ApsaraDB for MongoDB

Full-text search and vector retrieval in MongoDB typically require a separate search engine such as Elasticsearch, which adds architectural complexity and data synchronization overhead.

MongoDB Search embeds dedicated search nodes (mongot) in your instance, providing built-in full-text and vector search that you query with MQL—no external search system required.

Earlier MongoDB versions (3.2) supported Chinese full-text search through the analysis-aliws analyzer. This plug-in has been discontinued and is not supported in MongoDB 4.0 and later. If your instance is earlier than 8.3 and you need Chinese full-text search, use Monstache to sync data to Alibaba Cloud Elasticsearch and install the analysis-aliws plug-in there. MongoDB Search is supported on MongoDB 8.3 and later. It includes the built-in lucene.chinese Chinese analyzer, so you don't need to maintain a separate Elasticsearch system.

Billing

After you enable Search, mongot search nodes are billed based on the instance specification and storage space that you select. The actual prices are displayed on the buy page. Your primary MongoDB instance is still billed according to its existing billing rules.

Requirements

MongoDB Search is supported only on dedicated replica set or sharded cluster instances running MongoDB 8.3 or later.
Alibaba Cloud public regions only.
MongoDB 8.3 adds Auto Embedding: mongot automatically generates vectors when you write text, eliminating client-side embedding. MongoDB Search and model service usage example.

How it works

MongoDB Search adds dedicated mongot search nodes to your instance, keeping search workloads isolated from the core database (mongod nodes).

Core architecture: mongot nodes are independent compute resources that handle $search (full-text) and $vectorSearch (vector) queries.
Data synchronization: mongot nodes replicate the oplog from mongod nodes asynchronously via Change Streams, ensuring eventual consistency.
Query routing: When an aggregation contains $search or $vectorSearch, mongos routes the search portion to mongot, merges results with mongod data, and returns a unified result set.

Enable Search service

Purpose

Enable Search on an existing MongoDB instance to create dedicated mongot search nodes.

Procedure

Go to the Replica Set Instances or Sharded Cluster Instances page. In the top navigation bar, select the resource group and region to which the desired instance belongs. Then, find the instance and click the instance ID.
In the navigation pane on the left, select MongoDB Search.
On the MongoDB Search page, click Activate now.

In the Enable Search panel, configure the Search Node Specifications.

Parameter	Description
Specifications	Select a `mongot` node specification based on your expected QPS and data complexity.
Storage	Disk space for `mongot` search indexes, separate from primary instance storage. Choose a size based on your data volume and index complexity, and leave headroom for growth.

Set search node specifications and storage to at least match your primary instance. You can adjust later based on actual load.

Read and check Service Agreement.
Click Pay.

After creation, view Search node details on the MongoDB Search page. From there you can Upgrade/Downgrade, Restart, or Release the node.

Manage Search nodes

On the MongoDB Search page, you can:

Upgrade or downgrade: Adjust mongot node specifications or storage. Two Search nodes are provisioned by default; the node count cannot be changed.
Restart: Restart your mongot node for troubleshooting or configuration changes. The Search service is briefly unavailable during restart.
Release: Release your mongot node if you no longer need Search functionality.

Important
Releasing permanently deletes all Search indexes. This action cannot be undone.

Create and use Search indexes

Purpose

Create Search indexes for full-text or vector search using mongosh or a compatible MongoDB driver.

Prerequisites

You are connected to your target MongoDB instance using mongosh or your application.

Example 1: Full-text search on product reviews

Create a full-text Search index on the reviews collection and run keyword-based queries.

Create a Search index with dynamic mapping. dynamic: true indexes all fields automatically—ideal for prototyping.

// Create a Search index named 'reviews_full_text_index' on the 'reviews' collection
db.reviews.createSearchIndex({
  name: "reviews_full_text_index",
  definition: {
    "mappings": {
      "dynamic": true
    }
  }
});

Use the $search aggregation stage to find reviews by keyword. This query matches "good" in the comment field and returns the comment, rating, and product ID.

db.reviews.aggregate([
  {
    $search: {
      index: "reviews_full_text_index", // Specify the Search index to use
      text: {
        query: "good", // Search keyword
        path: "comment"      // Search in the 'comment' field
      }
    }
  },
  {
    $limit: 5
  },
  {
    $project: {
      _id: 0,
      productId: 1,
      rating: 1,
      comment: 1,
      score: { $meta: "searchScore" } // Return relevance score
    }
  }
]);

Example 2: Search by image using visual features

Create a vector search index on the images collection and run similarity searches against stored image vectors.

Create a vector Search index. Specify the vector field, numDimensions, and similarity metric.

// Create a vector index named 'vector_index' on the 'images' collection
db.images.createSearchIndex(
  "vector_index", 
  "vectorSearch", 
  {
    "fields": [
      {
        "type": "vector",
        "path": "plot_embedding_voyage_3_large",// Field storing vectors
        "numDimensions": 2048,// Vector dimensionality
        "similarity": "dotProduct",// Similarity metric
        "quantization": "scalar"
      }
    ]
  }
);

Use $vectorSearch to find similar images. Provide a queryVector, typically generated by an AI model from the input image.

numCandidates: the candidate set size. Higher values improve recall but increase resource usage and latency.

// Assume QUERY_EMBEDDING is a 1024-dimensional vector generated by an AI model
const QUERY_EMBEDDING = [0.12, 0.45, -0.23, ...]; // Example vector—replace with real data
// Retrieve based on vector similarity
db.images.aggregate([
  {
    "$vectorSearch": {
      "index": "vector_index",
      "path": "plot_embedding_voyage_3_large",
      "queryVector": QUERY_EMBEDDING,
      "numCandidates": 150,
      "limit": 10,
      "quantization": "scalar"
    }
  },
  {
    "$project": {
      "_id": 0,
      "plot": 1,
      "title": 1,
      "score": { $meta: "vectorSearchScore" }
    }
  }
])

Auto Embedding (new in 8.3)

MongoDB 8.3 introduces Auto Embedding. Specify the autoEmbed type when creating a vector index, and mongot automatically calls a specified embedding model such as text-embedding-v4 to generate vectors on document writes. At query time, pass natural-language text directly—the system converts it to a vector before searching.

Advantages over traditional vector search:

No embedding model SDK required in your application.
Vectors are generated and updated automatically on the database side, ensuring consistency.
Unified model proxying through the model service platform, supporting embedding, rerank, and Qwen-series LLMs.

For an end-to-end walkthrough covering model service setup, autoEmbed index creation, semantic search, and model invocation, see MongoDB Search and model service usage example.

Going live

Monitoring and operations

Monitoring metrics: mongot search nodes provide the following monitoring metrics, which you can view on the Monitoring and Alerting page in the console:

Metric	Description
CPU usage	CPU utilization of the search node
Memory usage	Memory utilization of the search node
IOPS usage / IOPS usage rate	I/O operations per second on the search node
Disk space usage / Disk space usage rate	Disk space consumption of the search node
MBPS / MBPS usage rate	Network throughput of the search node
Search node index field count	Number of indexed fields
Search node heap memory usage	JVM heap memory usage of the search node
Search node operation count	Number of query and write operations processed
Search node index disk space usage	Disk space used by search indexes
Search node Lucene document info	Document count and other Lucene index statistics
Search node sync latency	Data synchronization delay between the search node and primary instance

Log management: mongot nodes do not support operational, slow-query, or audit logs. Use explain() on $search or $vectorSearch stages to identify performance bottlenecks.
Index management: Run db.collection.getSearchIndexes() to view Search indexes and their status.

High availability and failover

Search nodes use a two-node configuration by default. If one node fails, the system automatically fails over to the remaining healthy node. Implement retry logic in your application.

Backup, restore, and data migration

Backup and restore: Instances restored from backups do not include search indexes. Re-enable Search and rebuild indexes on the restored instance.
Data migration: Data Transmission Service (DTS) and similar tools do not synchronize search indexes. Recreate indexes on the target instance after migration.

FAQ

Q: How long after writing data can I search it?

A: Data synchronization is asynchronous. Data typically becomes searchable within seconds, depending on write volume, document size, and network conditions.
Q: When is an index rebuild triggered? Does upgrading or downgrading trigger a rebuild?

A: Changing an index definition triggers an automatic background rebuild. The old index remains queryable until the new one completes. Node upgrades or downgrades do not trigger index rebuilds.