深入淺出存儲引擎

存儲引擎的細節寫的不錯，再結合代碼看更完美

找頁面置換算法的書，結果weread上只有這一本描述清楚了clock和改進型clock😂😂，很多操作系統書上面反而沒有，作者寫這本書應該下了很多功夫，讀一讀應該能有收穫，建議按需閱讀

一、存儲引擎的產生和作用什麼是存儲引擎？答：存儲引擎最基礎的目的就是管理用戶數據到盤上數據映射的模塊，用於讀取到對應寫到盤上對應的數據。存儲引擎的基本目標？答：能夠在4個背景（1、讀多寫少的業務，2、關係型數據庫是按照行格式存儲，3、千萬條數據量，4、要選擇底層本、大容量的持久化設備）下實現基礎的讀寫功能存儲引擎的終極目標？答：就是性能，要實現高效、快速的實現基本功能，評價性能指標：用戶請求耗時。 二、B+tree存儲引擎的特點B+tree的特點總結：B+tree作爲存儲引擎，是大多數讀多寫少業務的選擇，比如MySql，BoltDb等。其本質是由有序多叉樹+葉子節點保存value特點組成，並且葉子節點和節點之間，會鏈接起來，因此非常適合排序查詢+範圍查找。 磁盤特性：並且，由於磁盤順序IO速度 > 隨機IO速度，響應速度差了數量級以上，因此爲了保證儘量通過順序的IO來進行持久化，需要數據在下盤前在內存中進行排序並保證時間複雜度低，而具有排序能力的數據結構（跳錶、紅黑樹、AVL-tree、二叉排序樹、B樹、B+樹）。 選擇B+樹的原因：1、而爲了保證磁盤順序IO的特性，內存中排序好的數據要按照一定規則刷盤，一般採用操作系統內存操作的page size（4K）作爲閾值，這樣就能兼顧內存操作和磁盤順序的特性，那麼最合適的數據結構就是B樹/B+樹了。2、B樹是非葉子和葉子節點均保留原始數據，這樣的優點就是命中到非葉子節點的數據，不需要每次遍歷到葉子節點，就能直接返回，當然所帶來的問題也是顯而易見的，就是樹的層數會過高，單節點保存的數據量少，磁盤IO數量多，這樣性能不夠穩定。B+樹就是隻有葉子節點保留數據，那麼讀寫性能穩定，如果16K大小節點，數據kv佔用160B，索引kv佔16B，那麼3層b+樹就能存儲1億的數據。 實際工程KVS（key-value store）中的應用：MKV中kvs模塊，採用的數據結構就是B+樹，單node爲508字節，能保存差不多33個kv對象。 爲什麼kvs採用B+樹作爲存儲引擎的數據結構？其實還是業務導向的，主存dorado等面向的客戶都是toB的業務，運營商、銀行、國企等，場景基本就文件系統FS，或者LUN業務，特別是對於LUN業務來說，給客戶一個連續的空間自己使用，天然就是帶有順序性的，排序和範圍查詢就是重點。 KVS中的B+tree還有什麼優化？kvs索引裏面，key是由於poolkey+offset+cloneid+snapId組成的，poolkey又是根據lunid，shardid進行位運算組合到一起的，fs是根據fsId和fsname得到的。因爲key信息對於lun來說，很有可能多個key前綴是一樣的，這時候可以採用前綴壓縮的形式，壓縮空間。 三、LSM tree（log structured merge tree）存儲引擎的特點背景：大數據/雲計算等寫多讀少的業務，當前互聯網業務，每天會產生大量的中間用戶數據，比如點贊、評論等用戶數據用於推薦系統，或者系統的日誌信息用於鏈路監控，問題追蹤，此類業務均是寫多讀少，爲了保證該類型業務性能，再採用B+樹的索引結構，性能就較爲低下了。 LSM Tree的組成結構：memTable、ImmuMemTable、SSTable、WAL log這幾部分組成由於要保證寫性能，採用TVL格式（key，value，opType）進行追加寫，因此寫性能強，而同一時刻，同一個key會有多個value存在，有效的key就一個，爲了防止空間放大，需要採取對應手段進行優化——合併壓縮。爲了保證寫性能強，因爲要充分利用內存進行追加寫，但是內存雖然速度快，但是成本高，且斷電丟失，所以引入SSTable，用於索引數據下盤持久化。新寫的都是進入memTable，滿了之後轉爲ImmuMemTable，然後再轉爲SSTable，爲防止寫流程故障數據丟失，寫memTable之前都要寫WAL Log用於故障回放。 合併壓縮：SSTable一般分爲L0，L1和L2，每一層的key範圍不同，上層向下層轉換的流程是將（本層+下一層）重合的部分進行merge，然後生成新的子節點，合入到下一層SSTable裏，原始的兩個子節點釋放 讀性能優化：由於讀要通過memTable->ImmuMemTable->L0 SSTable -> L1 SSTable -> L2 SSTable一層一層往下找，查詢性能將會越來越差，因此一般會在每個table防止一個布隆過濾器，用於快速判斷key是否存在（但是有可能有假陽性問題，就是判斷存在實則不存在） 讀放大、寫放大、空間放大讀寫放大都是IO次數的放大，因爲LSM Tree都是非原位更新，導致了單個KV的更新，伴隨着多次merge磁盤IO，但是實際上B+tree雖然是原位更新，但是一樣有讀寫放大，因爲中間節點和其他元數據信息也伴隨磁盤IO。空間放大：比如你的IO大小爲100Byte，但是磁盤單次IO都是一個扇區，這種造成了空間放大。 四、故障處理一般的IO伴隨的是陣列運行數據、寫IO數據、寫IO的元數據，故障之後的處理手段原則都是回滾到操作前的狀態。對於運行數據，一般採用備份雙寫的形式，一個運行中出問題了，用另一個備份的覆蓋回滾寫IO的用戶數據，特別是寫了部分到磁盤上的數據出現故障場景，採用redo log的形式，每次寫之前進行寫log，內部信息爲key->old value，用於保留老數據回滾。對於元數據來說：所採用的也基本上是複本、鏡像、日誌的形式 五、事務處理ACID：針對於存儲引擎來說，必然伴隨着原子操作（A：原子性），單次更新涉及多個流程的，要麼都成功，要麼都失敗，事務執行成功之後狀態將會持久化保留（持久性），事務和事務之間不能互相影響（隔離性），保證了以上三點，就能保證整體的數據的一致性（比如：A給B轉賬前後，AB的賬戶總額不變）。隔離級別：多個事務併發互相影響的程度，一般分爲讀未提交（髒讀），讀已提交（幻讀），可重複度（不可重複讀），串行化，從前到後隔離成都越來越高，讀未提交風險最大，其他事務能夠讀取到本事務修改但是爲提交的數據（髒讀），由於兩次事務操作的時序問題，事務B兩次讀取事務A操作的值不同，彷佛幻覺一樣（幻讀），而事務B兩次讀取的數量不一樣，事務A進行了新增或者刪除（不可重複讀，是幻讀的一種特殊形式）MVCC：爲了保證多個事務併發執行的策略，多版本併發控制，一般有三種類型，基於鎖的，基於時間戳的，基於有效性檢查的 MDS（meta data store）中的應用，該模塊除了存儲對應的元數據外，還提供了元數據的事務操作，本身利用的是多版本併發控制，一共三個狀態，T0（已經提交成功的事務，也是外部讀能讀到的），T1（寫未提交），T2（寫已提交），並且元數據更新流程是採用副本更新，在原來的節點複製一個副本進行更新操作，然後從葉子節點，一層一層回寫到根節點。

就像後記中說的，作者看了很多現有的資料和書籍，加上大學教材中的基礎知識，還有幾篇自己的博客，彙編成了一本書。

作爲存儲入門比較合適；太多cs專業基礎知識的填充；lsm的概念大可不必如此泛化到包羅萬象；mq場景和類leveldb模式有着本質的不同、不建議相提並論

這本書最好的點是各種技術的推理演進過程，把基礎知識與成熟系統串起來了