mongoDB wiredTiger存儲引擎學習總結

時間 2019-12-04

標籤 mongodb wiredtiger 存儲引擎學習總結欄目 MongoDB 简体版

原文原文鏈接

1.wiredTiger

存儲引擎主要負責管理數據如何存儲在硬盤和內存上。mysql

1) mongoDB存儲引擎查看

mongoDB3.2版本以後選擇了wiredTiger做爲默認存儲引擎，查看數據庫存儲引擎語句以下：sql

db.serverStatus()
複製代碼

2）原理解析

wiredTiger經過Btree管理數據，B樹的數據結構以下圖。數據庫

1.MongoDB自己不支持事務實現，可是wiredTiger存儲引擎能夠經過事務快照和併發控制技術實現事務及ACID。緩存

2.Wiredtiger採用Copy on write的方式管理修改操做（insert、update、delete），修改操做會先緩存在cache裏，持久化時，修改操做不會在原來的leaf page上進行，而是寫入新分配的page，每次checkpoint都會產生一個新的root page。
Checkpoint時，wiredtiger須要將btree修改過的PAGE都進行持久化存儲數據結構

3.大部分數據庫採用的都是硬盤級索引，即MongoDB中每一個Btree節點爲一個page單位，其中在數據查找的過程當中，Btree結點上的數據須要以page爲單位從硬盤中加載到內存中，或者從內存中寫入硬盤；
4.mongoDB是文檔級數據存儲，數據存儲結構簡單，通常使用的需求都是IO次數少併發

對於mysql來講，B+樹的根節點和支結點不用存儲數據區域mvc

1.B+樹的存儲結構是這樣的，每一個節點保存的是關鍵字和指向下一個節點的指針； 2.和b tree 兩個明顯的區別就是，第一個是非葉子節點不保存數據區域，第二點是有左閉合區間，講一下數據規則；app

聊一下MongoDB和mysql的對比 1.Mysql關係型數據庫—須要範圍查詢 MongoDB 文檔級別不須要範圍查詢性能

2.mongoDB通常在設計的時候都是儘量的減小磁盤與硬盤之間的IO來提升性能；而Btree恰好是數據與關鍵字存放在同一個結點，因此mongoDB使用btreespa

3）爲何mysql使用B+ tree 而MongoDB用b tree；

1.首先是這樣每一個結點保存的關鍵字個數更多

2.每一個結點加載到內存中，若是不是葉子節點，就不用進行掃庫操做，若是是b樹，每次讀寫到內存的時候都須要掃庫；

3.B+ tree的葉子節點是以鏈表的時候把每一個點連在一塊兒，他們存儲是有序的，可使用範圍查詢

4.mongoDB通常在設計的時候都是儘量的減小磁盤與硬盤之間的IO來提升性能；而Btree恰好是數據與關鍵字存放在同一個結點，因此mongoDB使用btree

2.wiredTiger事務實現

MongoDB不只能將數據持久化存儲到硬盤文件中，並且還能將數據只保存到內存中；

而後不一樣的存儲引擎的區別就是使用了不一樣的存儲機制，鎖定技術，或者是索引技術等等；而後他們的性能也不同， WT實現事務須要用到這三個關鍵的技術：

Snapshot，MVCC Redo log；

定義了一個事務的總體全局對象wt_transaction，裏面包括id MVCC 多版本併發控制，基於keyvalue的value值的鏈表，主要是在鏈表裏存儲事務id 和本次事務下操做所修改的值。

下面分別介紹這幾個技術看看他們是如何實現事務的：

1）Snapshot

WT 引擎中的 snapshot_oject 是有一個最小執行事務 snap_min、一個最大事務 snap max 和一個處於 [snap_min, snap_max] 區間之中全部正在執行的寫事務序列組成。若是上圖在 T6 時刻對系統中的事務作一次 snapshot，那麼產生的T6 能訪問的事務修改有兩個區間：全部小於 T1 事務的修改 [0, T1) 和 [snap_min, snap_max] 區間已經提交的事務 T2 的修改。換句話說，凡是出如今 snap_array 中或者事務 ID 大於 snap_max 的事務的修改對事務 T6 是不可見的。若是 T1 在創建 snapshot 以後提交了，T6 也是不能訪問到 T1 的修改。這個就是 snapshot 方式隔離的基本原理。

2）MVCC

問題什麼是併發控制方法？

若是有人從數據庫中讀數據，有另外的人寫入數據，有可能讀數據的人看到的數據是不完整的，不一樣數據庫提出了不少方法來解決這個問題，解決這個問題的方法叫併發控制方法；

解決：mysql數據庫中對這個問題的解決方案是加鎖，經過加鎖，讓全部讀的用戶都等寫用戶工做完成，這個效率會比較差；而mongoDB中使用的MVCC：使用的是不一樣的併發控制方法

每次有寫操做以後，把修改後的內容以wt_mvcc的數據格式添加到紅色箭頭這個頭部；而後讀操做每次都是從鏈表頭根據對應的修改事務ID和本次讀操做的snapshot結合判斷是否能夠讀，若是不可讀，則往MVCC list尾方向移動，直到找到能讀的數據版本；

WT 中的數據修改都是在這個鏈表中進行 append 操做，每次對值作修改都是 append 到鏈表頭上，每次讀取值的時候讀是從鏈表頭根據值對應的修改事務 transaction_id 和本次讀事務的 snapshot 來判斷是否可讀，若是不可讀，向鏈表尾方向移動，直到找到讀事務能都的數據版本。樣例以下：上圖中，事務 T0 發生的時刻最先，T5 發生的時刻最晚。T1/T2/T4 是對記錄作了修改。那麼在 MVCC list 當中就會增長 3 個版本的數據，分別是 11/12/14。若是事務都是基於 snapshot 級別的隔離，T0 只能看到 T0 以前提交的值 10，讀事務 T3 訪問記錄時它能看到的值是 11，T5 讀事務在訪問記錄時，因爲 T4 未提交，它也只能看到 11 這個版本的值。這就是 WT 的 MVCC 基本原理。