偶然看到Wiredtiger團隊總監Michael Cahill，關於timestamp的一段視頻，寫成文字和大家share，如有錯誤，請及時指正。Michael Cahill在2011年與另一個合夥人共同開發了wiredtiger。
玩笑賀一航 - 玩笑
正文，以下為譯文，由於是視頻，所以難免有可能有錯誤領會的地方，如果有，請大仙們指正
——————————————————————————————
MongoDB 中的wiredtiger 是支持事務的一個數據庫引擎，而解決這個問題是比較困難的，這裡我將解釋他們是如何工作的，主要是此次的話題是圍繞著wiredtiger的時間戳。我們知道mongodb 中比較特殊的是oplog log ,簡稱為operation log,系統中的操作順序的記錄在oplog中，對於wiredtige 提供了一個一致性版本控制稱作多版本控制的東西，對於並行的處理中如何進行順序記錄的，如果不能確定準確的oplog 中的記錄順序，則複製集中的其他機器將不能獲得準確的數據複製順序。所以我們採用timestamp的方式來將信息更有效的在wiredtiger 中的storage laryer 層實現，並進行更有效的控制。
在開始講主題的之前，我們先回顧一下wiredtiger 的內部的數據存儲結構，無論是數據還是索引的存儲結構都是以樹狀結構存儲的，數據是以主鍵的樹形結構存儲，葉子節點中的key 和 values 是存儲在bson,無論你是插入一個新的document, 還是更新一個document 我們都稱之為update structure. 並且更新內部會帶有一些關於transaction的信息，是否與接下來的操作有關聯。當此時有讀操作進來，則他們需要考慮和計算給出正確的 lists 進行返回。
上面的工作其實就是多版本控制，這在MONGODB 存在了很長時間了，我們主要講的是，我們對現有的數據結構進行了改造，在數據結構中添加了時間戳，這個結構將告訴存儲引擎事務發生的順序。其實兩句話就可以解釋，timestamp 解決了事務的順序性以及讀取數據的是在哪個時間段的。這樣即使我們並行處理，摻雜進很多的不同的事務以及不同的順序，但timestamp 保證了正確的結果。
當我們使用了一個clever technique 將oplog並行通過多線程應用到其他的secondary mongodb上，並且這些數據塊被分割，在到目的端進行組合，應用。這些更新很可能不是按照順序，在primary上我們是按照 100 101 102的順序，而到了secondary 上很可能就變成 101 100 102 的順序。
那麼時間戳可以解決什麼問題
1 對於查詢，當101和102被應用後，100並未被應用在secondary上，則查詢中不會顯示 101 102 有關的數據， 這就保證了數據的一致性。
2 上面提到了oplog 會分割成多個batches 被多個線程來應用，而在從庫上讀取是使用locks 來進行的，在MONGODB 有一個global lock 在 secondary 上釋放這個全局鎖，那應用的數據再能在，secondary 上被讀取。這樣的可以引申到在唯一索引的document上，在有兩個線程操作的documents上，我們必須要讓所有的結果是正確的。
3 timestamp 同時也要應用到複製中的rollback ，在講之前大家應該都明白MONGODB 複製中的大多數的概念。通過上圖我們可以通過對比時間戳來獲得大多數的secondary 上2 號數據點已經被應用。這將對節點失敗後的選舉等等都有相關的聯繫。同時對於節點切換後的數據拽取都有相關的作用。
同時在新主產生後，我們也會有相關的歷史數據決定舊的主是否還能rejoin進複製集中，上圖很明顯older prmary將不能被重新加入到複製集中。
總結上面的東西，wiredtiger 通過timestamp的排序工作對例如複製， 數據回滾，以及與index 有關的維護工作進行了有益的支持，下一步我們將針對索引的維護工作進行優化，將兩種建立索引的優點合二為一，同時 我們會對long -running reads 方面的工作進行優化，現在的事務基本是基於 short running transactions, 但我們知道現在有一些客戶查詢大量的數據的事務，我們目前正在做一些底層的工作，使得我們的數據庫引擎更加有效的處理類似的工作。
閱讀更多 Austin的數據庫 的文章
