Transferred from: http://www.ha97.com/4580.html
This picture is from Ricky Ho's blog, MongoDB Architecture (MongoDB Architecture), which is a very broad topic to listen to, but the author does have an analysis of MongoDB's internal-to-external architecture in the article. In this paper, we take a brief description of several key architectural slices in the article. Hope to be useful to everyone.
MongoDB Data File internal structure
- MongoDB is partitioned on the Datastore by namespace, a collection is a namespace, an index is also a namespace
- Data from the same namespace is partitioned into multiple extent,extent using a doubly linked list connection
- In each extent, the data for each row is saved, which is also connected by a two-way link
- Each row of data storage includes not only the data footprint, but also some additional space, which makes it possible to not move the location after the data update has become large
- Indexes are implemented in the BTREE structure
Related reading: The internal structure of MONGODB data files
Implementing Transactions in MongoDB
It is well known that MongoDB only supports atomic modification of single-line records and does not support atomic manipulation of multiple rows of data. But through the abnormal operation, you can actually implement the transaction yourself. The steps are not:
- The 1th step: Record a transaction record, the modified value of the multiline record to be modified is written inside, and set its state to Init (if the operation is interrupted at this time, then at the restart, it will be determined that he is in the Init state, so that its saved multi-line modification operation to apply to the specific line)
- 2nd step: Then update the specific line to be modified, write the identity of the transaction record you just wrote to its Tran field
- 3rd Step: Change the state of the transaction record from Init to Pending (if at this time the operation is interrupted, then at the restart, it will be judged that its state is pending, then see all its corresponding records to be modified, if its Tran has a value, then 4th step, if not value, Note that the 4th step has been executed, and the state is directly changed from pending to commited.
- 4th step: Modify the corresponding values of the multiple records that need to be modified, and unset the previous Tran field
- 5th step: Change the state of the transaction record from pending to commited, the transaction completes
In fact, the above steps are not uncommon, and in a DBMS that supports transactions, the assurances of atomicity of their transactions are mostly similar to the above. In fact, the Tran record of the transaction record is similar to the redolog in these DBMS.
MongoDB Data Synchronization
is MongoDB using replica sets mode of synchronization process
- A red arrow indicates that the write is written to primary, and then asynchronously synchronizes to multiple secondary
- A blue arrow indicates that the read operation can be read from either primary or secondary
- Heartbeat synchronization is maintained between each primary and secondary to determine the status of replica sets
Shard mechanism
- MongoDB shards are specified as a shard key to be performed, the data is divided into different chunk by range, and the size of each chunk is limited
- There are multiple shard nodes that save these chunk, and each node holds a portion of the chunk
- Each shard node is a replica sets, which guarantees the security of the data
- When a chunk exceeds its limit of maximum volume, it splits into two small chunk
- Chunk migration action is raised when the chunk is unevenly distributed across the Shard nodes
Server role
This is the standard for sharding, and here are some of the node roles that are specific to sharding
- Client Access routing node MONGOs for data read and write
- The config server holds two mappings, one is the mapping of which chunk is the interval of the key value, and the other is the mapping of which shard node exists in chunk
- The routing node obtains the data information through the config server, and through this information, it finds the corresponding operation of the Shard node that actually holds the data.
- The routing node also determines whether the current chunk is out of bounds in the write operation, and if so, it is divided into two chunk
- For queries and update operations by Shard Key, the routing node will find the specific chunk and then do the related work
- For queries and update operations that do not press shard Key, MONGOs sends a request to all subordinate nodes and then merges the returned results
For more details please see the original: MongoDB Architecture
Translation: http://blog.nosqlfan.com/html/3887.html
MongoDB architecture--Remember to combine the previous article to see that the picture inside is very good
