Concept | Description |
Region | The geographic location of the server of the ApsaraDB for MongoDB instance that you purchase. You must specify a region when you purchase an ApsaraDB for MongoDB instance and cannot change the region after purchase. 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. The specified region must be the same as that of the ECS instance. For more information about how to connect to an ApsaraDB for MongoDB over the internal network, see Connect an ECS instance to an ApsaraDB for MongoDB instance across zones over the internal network.
|
Zone | The physical area that has an independent power supply and network in a region. Zones in a region can communicate over the internal network. Network latency for resources within the same zone is lower than that for resources across zones. Faults are isolated between zones. In the single-zone deployment mode, the three nodes of an ApsaraDB for MongoDB replica set instance are deployed in the same zone. If an ECS instance and an ApsaraDB for MongoDB instance are both deployed in the same zone, network latency is reduced.
|
Instance | An ApsaraDB for MongoDB instance is the basic unit of ApsaraDB for MongoDB. An instance is the runtime environment for ApsaraDB for MongoDB and exists as a separate process on a host. You can create, modify, and delete an instance in the ApsaraDB for MongoDB console. Instances are independent, and their resources are isolated. They do not compete for resources such as CPU, memory, or I/O. Each instance has its own features, such as database engine and version. The system controls instance behavior by using corresponding parameters.
|
Memory | The maximum memory that an instance can use. |
Disk capacity | The disk size that you select when you create an ApsaraDB for MongoDB instance. Disk capacity is occupied by the collection data and the data required for normal instance operations such as system databases, database rollback logs, redo logs, and indexes. Make sure that an ApsaraDB for MongoDB instance has sufficient disk capacity to store data. Otherwise, the instance may be locked. If the instance is locked due to insufficient disk capacity, you can unlock the instance by expanding the disk capacity.
|
IOPS | The maximum number of read/write operations performed per second on block devices at a granularity of 4 KB. |
CPU | The maximum computing capability of an ApsaraDB for MongoDB instance. CPU cores use the X86 architecture. A single Intel Xeon series CPU core has at least 2.3 GHz of computing power with hyper-threading capabilities. |
Connections | The number of Transmission Control Protocol (TCP) connections between a client and an ApsaraDB for MongoDB instance. If the client uses a connection pool, the connections between the client and the instance are persistent connections. Otherwise, they are short-lived connections. |
Sharded cluster instance | ApsaraDB for MongoDB supports the sharded cluster architecture. You can purchase multiple mongos nodes and shards and one ConfigServer component to build a sharded cluster instance, which serves as a MongoDB distributed database system. |
Mongos | The routing service that processes requests. All requests must be coordinated by using mongos that serves as a request distribution center and forwards data requests to the corresponding shard server. You can use multiple mongos nodes to process requests. If one mongos node fails, other mongos nodes can continue to process the requests.
|
Shard | A shard in a sharded cluster instance. Each shard can be deployed as a three-node replica set to increase availability. You can create multiple shards to improve read/write performance and expand storage capacity. This way, you can implement a MongoDB distributed database system based on your application performance and storage requirements.
|
ConfigServer | A configuration server that stores all database metadata for mongos nodes and shards in an ApsaraDB for MongoDB sharded cluster instance. Mongos nodes cache shard data and data routing information in their memory, whereas the ConfigServer component stores such data. When mongos nodes in a sharded cluster instance are started for the first time or shut down and then restarted, they load configuration information from the ConfigServer component. If the information of the ConfigServer component changes, all mongos nodes are notified to update their status. This ensures that mongos nodes can always obtain the correct routing information. The ConfigServer component stores the metadata of shards and routers and have high requirements for service availability and data reliability. ApsaraDB for MongoDB uses three-node replica sets to ensure the reliability of the ConfigServer component.
|