This page defines the terms used in ApsaraDB for MongoDB, grouped by concept layer to help you understand how infrastructure, instance specifications, and sharded cluster components relate to each other.
Infrastructure
| Term | Description |
|---|---|
| Region | The geographic location where your ApsaraDB for MongoDB instance runs. Specify the region at purchase — it cannot be changed afterward. When you purchase an ApsaraDB for MongoDB instance, you must use an Elastic Compute Service (ECS) instance. ApsaraDB for MongoDB supports access over the internal network. To connect over the internal network, the ECS instance and the ApsaraDB for MongoDB instance must be in the same region. For details, see Connect an ECS instance to an ApsaraDB for MongoDB instance across zones over the internal network. |
| Zone | A physically isolated area within a region that has an independent power supply and network. Zones within the same region communicate over the internal network, so latency between zones is higher than within a single zone. Faults in one zone do not affect other zones. In single-zone deployment mode, all three nodes of a replica set instance are placed in the same zone, keeping latency between an ECS instance and the database instance reduced. |
Instance and specifications
An instance is the basic unit of ApsaraDB for MongoDB — a separate process on a host with isolated CPU, memory, and I/O resources. Create, modify, and delete instances from the ApsaraDB for MongoDB console. Each instance runs a specific database engine version, and its behavior is controlled by the corresponding parameters.
The following specifications define the resource limits of an instance:
| Specification | Description |
|---|---|
| Memory | The maximum amount of memory the instance can use. |
| Disk capacity | The storage size you select when creating the instance. Disk capacity is consumed by collection data, system databases, database rollback logs, redo logs, and indexes. If the instance runs out of disk space, it is locked. Expand the disk capacity to unlock it. |
| IOPS | The maximum number of read/write operations per second on block devices, measured at a 4 KB granularity. |
| CPU | The maximum computing capacity of the instance. CPU cores use the X86 architecture. A single Intel Xeon core delivers at least 2.3 GHz of computing power with hyper-threading. |
| Connections | The number of Transmission Control Protocol (TCP) connections between a client and the instance. If the client uses a connection pool, the connections are persistent. Otherwise, they are short-lived. |
Sharded cluster
A sharded cluster instance is a MongoDB distributed database system built from three types of components: multiple mongos nodes, multiple shards, and one ConfigServer. Together, they distribute data and route queries across the cluster.
| Component | Description |
|---|---|
| Mongos | The routing layer of the sharded cluster. All client requests go through mongos, which acts as a request distribution center and forwards each request to the correct shard. Deploy multiple mongos nodes so that if one fails, the others continue processing requests. |
| Shard | Stores a subset of the cluster's data. Each shard is deployed as a three-node replica set for high availability. Add more shards to increase read/write throughput and expand storage capacity. |
| ConfigServer | Stores all metadata for the sharded cluster, including shard assignments and routing information. Mongos nodes cache shard data and data routing information in their memory, whereas the ConfigServer stores such data persistently. When a mongos node starts or restarts, it loads its configuration from the ConfigServer. If the ConfigServer data changes, all mongos nodes are notified to update their status. ApsaraDB for MongoDB deploys the ConfigServer as a three-node replica set to ensure reliability. |