MongoDB架构图解
生活随笔
收集整理的這篇文章主要介紹了
MongoDB架构图解
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
? ? ? ? ? ? ? ? ? ? ? ? ? ?MongoDB架構圖解
本文圖片來自Ricky Ho的博文MongoDB構架(MongoDB?Architecture),這是個一聽就感覺很寬泛的話題,但是作者在文章中確實對MongoDB由內至外的架構進行了剖析。本文截取了其文章中的幾張重點架構示意圖片進行簡單描述。希望對大家有用。
MongoDB數據文件內部結構
相關閱讀:《MongoDB數據文件內部結構》
在MongoDB中實現事務
眾所周知,MongoDB只支持對單行記錄的原子性修改,并不支持對多行數據的原子操作。但是通過上圖中的變態操作,實際你也可以自己實現事務。其步驟如圖所未:
- 第1步:先記錄一條事務記錄,將要修改的多行記錄的修改值寫到里面,并設置其狀態為init(如果這時候操作中斷,那么在重新啟動時,會判斷到他處于init狀態,從而將其保存的多行修改操作應用到具體的行上)
- 第2步:然后更新具體要修改的行,將剛才寫的事務記錄的標識寫到它的tran字段中
- 第3步:將事務記錄的狀態從init變成pending(如果在這時候操作中斷,那么在重新啟動時,會判斷到它的狀態是pending的,這時候查看其所有對應的多條要修改的記錄,如果其tran有值,那么就進行第4步,如果沒值,說明第4步已經執行過了,直接將其狀態從pending變成commited了就行)
- 第4步:將需要修改的多條記錄的相應值修改了,并且unset掉之前的tran字段
- 第5步:將事務記錄那一條的狀態從pending變成commited,事務完成
其實上面的步驟并不罕見,在支持事務的DBMS中,其事務原子性提交的保證大多都與上面類似。其實事務記錄的tran那條記錄,就類似于這些DBMS中的redolog一樣。
MongoDB數據同步
上圖是MongoDB采用Replica Sets模式的同步流程
- 紅色箭頭表示寫操作寫到Primary上,然后異步同步到多個Secondary上
- 藍色箭頭表示讀操作可以從Primary或Secondary任意一個上讀
- 各個Primary與Secondary之間一直保持心跳同步檢測,用于判斷Replica Sets的狀態
分片機制
- MongoDB的分片是指定一個分片key來進行,數據按范圍分成不同的chunk,每個chunk的大小有限制
- 有多個分片節點保存這些chunk,每個節點保存一部分的chunk
- 每一個分片節點都是一個Replica Sets,這樣保證數據的安全性
- 當一個chunk超過其限制的最大體積時,會分裂成兩個小的chunk
- 當chunk在分片節點中分布不均衡時,會引發chunk遷移操作
服務器角色
上面講了分片的標準,下面是具體在分片時的幾種節點角色
- 客戶端訪問路由節點mongos來進行數據讀寫
- config服務器保存了兩個映射關系,一個是key值的區間對應哪一個chunk的映射關系,另一個是chunk存在哪一個分片節點的映射關系
- 路由節點通過config服務器獲取數據信息,通過這些信息,找到真正存放數據的分片節點進行對應操作
- 路由節點還會在寫操作時判斷當前chunk是否超出限定大小,如果超出,就分列成兩個chunk
- 對于按分片key進行的查詢和update操作來說,路由節點會查到具體的chunk然后再進行相關的工作
- 對于不按分片key進行的查詢和update操作來說,mongos會對所有下屬節點發送請求然后再對返回結果進行合并
更多詳細內容請看原文:MongoDB Architecture
翻譯:http://blog.nosqlfan.com/html/3887.html
與50位技術專家面對面20年技術見證,附贈技術全景圖
總結
以上是生活随笔為你收集整理的MongoDB架构图解的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SQL解析器的性能测试
- 下一篇: 海量数据 - join处理