DDS Indexing

Document Database Service (DDS) indexes are high-performance data retrieval structures developed based on the MongoDB protocol. They support various index types, including single-field, compound, TTL, sparse, and partial indexes, while extending enterprise-grade features such as hidden indexes and wildcard indexes. Their core objective is to significantly boost query performance by minimizing full-table scans and optimizing sorting and aggregation operations. DDS is fully compatible with MongoDB indexes and query syntax. It leverages a high-performance cloud-native storage engine combined with sharded cluster and replica set architectures to deliver high availability and elastic scalability.

Why You Need DDS Indexing

Accelerated queries: In collections with millions of documents, indexes reduce query response times from minutes to milliseconds, lowering time complexity from O(n) to O(log n).
Support for complex operations:
- Optimized sorting: Indexes directly return sorted results to avoid full-table scans (example: db.collection.find().sort({field:1})).
- Accelerated aggregation: Compound indexes optimize $group and $match operations to reduce intermediate data volume.
Enterprise-grade requirements: In IoT scenarios involving terabytes of device logs, indexes are essential for guaranteeing real-time query performance.

Advantages

The core advantage of DDS indexing is its full compatibility, high elasticity, fine-grained control, and intelligent performance assurance, as described in Table 1.

**Table 1** Advantages of DDS indexing
Advantage	Description
Compatibility	Fully compatible with MongoDB index types (such as single-field, compound, and TTL indexes), with extended support for hidden and wildcard indexes.
Cloud-native optimization	Supports elastic scaling, automated backup, and intelligent index distribution across sharded clusters, and works with replica sets to ensure high availability.
Flexible control	Supports sparse indexes (indexing only documents containing fields) and partial indexes (indexing only documents meeting specific conditions).
Performance assurance	Analyzes query execution plans using explain() to automatically identify the best index path.

Use Cases

**Table 2** Use cases of DDS indexing
Scenario	Query Requirements	Index Policy	Technical Value
E-commerce product search and recommendation	Multi-dimensional filtering across categories, price ranges, brands, and ratings	Compound index: {category: 1, price: 1, brand: 1}	Avoids full-table scans, enabling millisecond-level product list loading and sorting.
Financial transaction audit	Querying a specific user's transaction records by time range	Compound index: {userId: 1, timestamp: -1}	Rapidly locates a user's latest transactions to meet real-time compliance audit requirements.
Real-time logistics tracking	Querying the latest location and historical tracks using a waybill number	Unique index {trackingNumber: 1} + TTL index {createdAt: 1}	Ensures query efficiency, optimizes storage space, and automatically deletes expired data.
CMS tag-based search	Filtering articles by using combinations of multiple tags	Multi-key index on the tags field	Supports rapid array element matching for flexible content classification and precise retrieval.
Monitoring alarm time-series data processing	Storing device monitoring metrics and periodically purging expired data	TTL index: {createdAt: 1} (expireAfterSeconds: 604800)	Automates data lifecycle management to reduce manual maintenance costs.
Location-based services (LBS)	Searching for nearby merchants based on geographic location	Geospatial index: (2dsphere)	Supports distance calculations and range queries for precise location-based recommendations.

How DDS Indexing Works

DDS indexing involves multi-component collaboration designed to achieve efficient querying across massive document volumes.

Core storage and data structure layer
- B+ tree index structure: This forms the static data structure foundation of DDS indexes. When you create an index, the storage engine sorts the values of specified fields to construct a B+ tree. Non-leaf nodes store only field values for navigation, while all actual data pointers (pointing to document disk locations) reside in the leaf nodes, which are linked via pointers. This structure excels at range queries and sorting because it requires traversing only the linked list of leaf nodes.
Distributed architecture layer
- Sharded cluster
  - Index distribution: In a sharded cluster, indexes are not unified into a single global structure. Each shard stores and maintains exclusively the indexes for its own data. For example, in a collection sharded by userId, indexes are similarly distributed across shards.
  - Query routing: Upon receiving a query, the router (mongos) first analyzes the criteria. If the query includes the shard key (for example, userId), the router directly routes the request to the target shard for a directed query. Otherwise, it executes a scatter-gather query across all shards and aggregates the results.
- Replica set
  - High availability: Indexes automatically replicate from the primary node to all secondary nodes in a replica set. This ensures that if the primary node fails and a secondary node is voted, index availability and query continuity remain uninterrupted.
  - Read/write splitting: Read requests can be offloaded to secondary nodes, and their indexes are used to relieve query pressure on the primary node.
Lifecycle management layer
- TTL indexing: A specialized single-field index used to automatically purge expired data based on a designated expiration time (expireAfterSeconds) designated during index creation. DDS launches a background thread that periodically scans index field values against the current time, If their lifespan exceeds the threshold, DDS automatically deletes documents and clears corresponding index entries. This is ideal for scenarios like session management and log storage.

Types of DDS Indexes

**Table 3** Types of DDS indexes
Type	Description	Scenario
Default index	An automatically created unique index on the _id field; cannot be deleted.	Preventing the insertion of duplicate documents.
Single-field index	An ascending or descending index created for a single field, for example, db.collection.createIndex({field:1}).	Simple queries. Example: {field: "value"}
Compound index	A multi-field combination index, for example, {userid:1, score:-1}, adhering to the leftmost prefix rule.	Multi-condition queries. Example: {userid: "A", score: >80}
Multi-key index	Automatically created for each element of an array field, supporting array queries such as $in.	Tag classification. Example: {hobbies: ["reading", "sports"]}
TTL index	Automatically deletes expired documents based on a timestamp field, for example, log deletion.	Temporary data storage, such as session caches
Partial index	Indexes only documents meeting specific criteria, for example, {partialFilterExpression: {age: {$gt: 18}}}.	Data filtering, for example, indexing only active users
Sparse index	Indexes only documents containing the target field; suited for high field-absence rates.	Optional fields. Example: {optionalField: 1}
Wildcard index	Supports dynamic field matching, for example, {** : 1}; suited for nested structures.	Dynamic JSON fields. Example: {user.profile.name: 1}

DDS Indexing vs. MongoDB Indexing

While both DDS and MongoDB indexes rely on identical B+ tree and WiredTiger storage engine technologies, they differ significantly in service models, O&M features, and enterprise-grade capabilities, as outlined in Table 4.

**Table 4** DDS indexing vs. MongoDB indexing
Item	DDS Indexing	MongoDB Indexing
Cloud native features	Integrates cloud services like auto scaling, automated backup, and disaster recovery to simplify O&M.	Requires manual management of sharding, backup, and high availability.
TTL index optimization	Employs a more efficient TTL cleanup mechanism to avoid the accumulation of expired data.	Relies on background threads, which may suffer cleanup delays under heavy data loads.
Index type extension	Introduces enterprise features such as wildcard and hidden indexes.	The standard edition supports single-field, compound, and TTL indexes, but lacks hidden indexes.
Performance and availability	Leverages sharding and replica sets to better handle high concurrency, supporting online scaling.	Requires manual configuration of sharding and replica sets, with scalability depending on manual operations.