Document directory
- Internal Structure of MongoDB data files
- Implement transactions in MongoDB
- MongoDB Data Synchronization
- Sharding Mechanism
- Server role
The image in this article is from Ricky Ho's blog MongoDB Architecture. This is a very broad topic, however, in the article, the author does analyze the MongoDB internal-External architecture. This article provides a brief description of several key architecture films in the article. I hope it will be useful to you.
Internal Structure of MongoDB data files
- MongoDB is divided by namespaces in data storage. A collection is a namespace, and an index is also a namespace.
- Data in the same namespace is divided into multiple Extent, and Extent is connected by a two-way linked list.
- Each Extent stores the data of each row, which is also connected through two-way links.
- Each row of data storage space includes not only space occupied by data, but also some additional space, which makes it possible to move the location after data update becomes larger.
- Indexes are implemented in the BTree structure.
Implement transactions in MongoDB
As we all know, MongoDB only supports atomic modification of single-row records, and does not support atomic operations on multi-row data. However, during abnormal operations, you can also implement transactions on your own. The steps are not:
- Step 2: first record a transaction record, write the modified values of the multi-row record to be modified into it, and set its status to init (if the operation is interrupted at this time, then during restart, it will be determined that he is in the init state, so that he can apply the multi-row modification operation he saves to a specific row)
- Step 2: update the Specific Row to be modified and write the identifier of the transaction record you just wrote to its tran Field
- Step 1: change the state of the transaction record from init to pending (if the operation is interrupted at this time, it will be determined that its State is pending at the time of restart, at this time, check all the corresponding records to be modified. If its tran has a value, perform Step 1. If there is no value, it indicates that step 2 has been executed, directly change its status from pending to commited)
- Step 1: Modify the values of multiple records to be modified, and unset the original tran field.
- Step 2: change the state of the transaction record from pending to commited, and the transaction is completed.
In fact, the above steps are not uncommon. In the DBMS that supports transactions, the guarantee of transaction atomic commit is mostly similar to that above. In fact, the tran record of the transaction record is similar to the redolog in these DBMS.
MongoDB Data Synchronization
It is the synchronization process in MongoDB's Replica Sets mode.
- The red arrow indicates that the write operation is written to Primary and then asynchronously synchronized to multiple Secondary instances.
- The blue arrow indicates that the read operation can be read from any of the Primary or Secondary
- Each Primary and Secondary keeps heartbeat synchronized detection, used to determine the status of Replica Sets
Sharding Mechanism
- A shard key is specified for MongoDB. Data is divided into different chunks by range. The size of each chunk is limited.
- Multiple shard nodes save these chunks, and each node saves some of the chunks.
- Each shard node is a Replica set to ensure data security.
- When a chunk exceeds its maximum volume, it is split into two small chunks.
- When the chunk is unevenly distributed among the shard nodes, the chunk migration operation is triggered.
Server role
The above describes the sharding standards. Below are the specific node roles during the sharding process.
- The client accesses the routing node mongos for data read and write.
- The config server stores two mappings. One is the Ching between chunks corresponding to the key value range, and the other is the ing between chunks and shard nodes.
- The routing node obtains the data information through the config server and finds the shard node that actually stores the data for corresponding operations.
- During the write operation, the route node determines whether the current chunk exceeds the limit. If the limit is exceeded, the nodes are divided into two chunks.
- For the query and update operations by shard key, the routing node will find the specific chunk and then perform relevant work.
- Mongos sends requests to all subordinate nodes and then merges the returned results for queries and update operations without sharding keys.
For more details, see the original article: MongoDB Architecture
