?我一直以來都在不斷的研究和探索數據庫的內部存儲原理。我認為這個話題是非常巨大且復雜的，我努力所學也只占其千萬分之一。我將會講解一些數據庫存儲的內部機制，數據庫是如何進行優化操作來提供驚人速度及其優勢和缺點。

?當我們談起數據庫內部存儲結構時，人們都會想到B樹或者B+樹，但是我們在這里并不會談論這些數據結構的原理，我們會展示這些數據結構為什么適合作為數據庫存儲的內部結構以及使用這些數據結構的目的。

?傳統的關系型數據將數據以B樹的形式存儲在磁盤上，它們也會在RAM上使用B樹維護這些數據的索引，來保證更快的訪問速度。插入的行存儲在B樹的葉子節點上，所有的中間節點用來存儲用于導航查詢語句的原數據。

    因此，當有數以百萬計的數據被插入到數據庫中時，索引和數據存儲會變得十分大。因此，為了快速的訪問，需要從磁盤中加載所有數據到內存，但是RAM一般沒有這么大的空間來存儲所有的數據。因此，數據庫必須從磁盤中讀取部分數據。這種加載數據的場景如下圖所示：

 

?磁盤I/O花費的時間很長，是影響數據庫性能的主要原因之一。B樹是支持隨機讀寫，in-place 替換,十分緊湊并且自平衡的數據結構，但是受磁盤I/O速度的限制。隨機讀意味著當訪問磁盤數據時，磁頭必須移動到柱面上的指定位置，因此會消耗大量時間。

?B樹被設計為使用block的形式存儲數據，因為操作系統讀取讀取一個block的數據要比讀取單獨字節數據要快的多。MySQL的InnoDB存儲引擎的block大小為16KB。這意味著每次你讀取或者寫入數據時，大小為16KB的block數據會被從磁盤加載到RAM中，它會被寫入新的數據，并且再次寫回到磁盤上。假設數據庫表的每一行數據為128字節（實際大小會變化），一個block（葉子節點）為16KB，存儲了(16 * 1024) / 128 = 128行數據。

    B樹的高度一般小于10，但是每一層的節點數量卻很多，由此可以管理數以萬計的數據。基于上述特性，B樹適合作為數據內部存儲結構。

?因此，在B樹上進行讀操作是相對來說比較快速的，因為該操作只需要遍歷一些節點并且進行較少次數的磁盤I/O請求。而且，范圍查詢因為可以將數據以block的形式進行獲取和操作而速度更快。你可以進行下列操作來讓基于B-Tree的數據庫性能更好：

    減少索引節點數量：這是提升關系型數據庫性能的常用策略。索引越多，插入和更新操作需要管理的索引數量也越多。當數據庫數據運行時間越來越久時，就需要刪除一些老舊或者無用的索引，并且謹慎地添加新的索引。但是你也要注意，索引越少意味著查詢性能越差，你需要在查詢性能和插入更新性能之間進行取舍(譯者注：可以考慮數據庫的讀寫比率)。

    順序插入：如果你能以主鍵大小為基礎進行大量數據的順序插入，那么插入數據的速度會十分的快。因為在插入過程中，插入行所屬的block已經在內存中，所以數據庫可以直接將行插入到內存的數據結構中，然后通過一次磁盤I/O提交到數磁盤中。當然，這些都取決于數據庫的具體實現，但是我認為現代的數據庫一般都會進行類似的優化。

?但是B樹并不是適合所有情景的最優存儲結構。對B樹結構的寫操作性能很差，比隨機讀還要差，因為數據庫必須從磁盤中加載數據對應的頁，然后修改它并沖洗新寫入到磁盤中。隨機寫入時平均有100字節每秒寫入速度，這個限制是由于磁盤的基本工作原理。

    事實上，簡單依賴于緩存的使用，索引搜索和更多的內存可以處理更多的讀操作，但是應付更多的寫操作就比較麻煩。當你需要寫入或更新大量的數據時，B樹結構并不是最正確的選擇。長久以來，傳統數據庫進行了大量的優化，比如說InnoDB嘗試使用緩沖來減少磁盤I/O操作。具體操作如下所示：

 

?數據庫寫操作可以通過提升磁盤的帶寬來提升速度，但是目前關系型數據庫都沒有這樣做。而且關系型數據庫管理系統一般都是十分復雜的，因為他們使用鎖，并發，ACID事務等操作，這使得寫入操作更加復雜。

?當今信息時代，在比如消息、聊天、實時通訊和物聯網等客戶為中心的服務和大量無結構化數據的分布式系統中，每小時都會進行數百萬計的寫入操作。因此，這些系統是以寫為主的系統，為了迎合這些系統的需要，數據庫需要能夠擁有快速插入數據的能力。典型的數據庫并不能很好的滿足類似的場景，因為它們無法應付高可用性，盡可能的最終一致性，無格式數據的靈活性和低延遲等要求。

?LSM樹(Log Structured Merge Tree)應運而生。LSM并不是一種類似于B樹的數據結構，而是一個系統。在LSM系統中，并沒有對數據的in-place替換；一旦數據被寫入磁盤，它就再也不會被修改。顯然，它是一種只能在末尾添加(append only)的寫入系統。一些日志結構的文件系統比如ext3/4也使用類似的原理。

    因此，該系統就如同順序的記錄數據日志一般。基本上，LSM系統利用了順序寫的優勢。傳統的磁盤驅動的寫操作最高可以達到100MB/s，現代的固態硬盤在順序寫時的速度則更快。事實上，固態硬盤驅動有一些內置的并行機制來讓它可以同時寫入16到32MB的數據。LSM樹和固態硬盤的特性十分匹配。順序寫要比隨機寫快很多。

?為了正確地理解上述場景，讓我們簡單的看一下Facebook的Cassandra數據庫是如何使用LSM原則的。

 

?Cassandra或者任何LSM系統都會維護一個或者多個用來在寫入磁盤前存儲數據的內存數據結構(如上圖中的memtable)，比如說子平衡樹(AVL)、紅黑樹、B樹或者跳表。該內存數據結構維護一個排序的數據集。

    不同的LSM實現互使用不同的數據結構來適應不同的需求，并不存在標準的LSM實現。當內存中存儲的數據超過配置的閾值時，內存中存儲的數據就會被放置在將會被寫入磁盤的隊列中。為了flush數據，Cassandra順序地寫入排序的數據到磁盤中。

    磁盤維護一個叫做“SSTable”(Sorted Strings Table)的數據結構，該數據就是寫入文件數據的有序的快照，SSTable是不可變的。LSM系統可以管理磁盤上的多個文件。

?因此，如果數據在內存中沒有被發現，Cassandra需要掃描所有磁盤上的SSTables來搜索該數據。因此，Cassandra的讀操作相對來說要比寫操作慢，但是這里有一些可以處理的方法。Cassandra或者其他LSM系統會在后臺運行壓縮程序來減少SSTable的數量。壓縮程序對SSTable進行歸并排序，在新的SSTable找那個插入新的排序數據并且刪除老的SSTables。但是使用壓縮程序有時候無法應付數據庫中數以百萬計的更新操作。

    因此，一些概率數據結構(probabilistic data structures)比如Bloom filters被應用來快速判斷是否一些數據存在于SSTable。Bloom filters十分適合對內存中的數據進行判斷，因為它需要進行大量的隨機查詢來進行數據是否存在的概率性判斷。Bloom filters算法可以極大地減少遍歷查詢SSTables的花費。因此，LSM系統解決了在大數據中寫操作需要花費大量時間的問題。

    LSM系統也有Read amplification的問題-會讀取出比它實際需要更多的數據。因此，還有介于B Tree和LSM Tree之間的解決方法來給出我們最優（不一定準確）的讀寫效率嗎？

?Fractal Tree Index是基于B-Tree的數據結構。依據開發人員給出的benchmark，該數據結構有比B-Tree更優良的性能。Fractal tree支持在非葉節點上的信息緩存。MySQL的高性能存儲引擎Tokudb就使用了Fractal tree。

 

?如上圖所示，在Fractal Tree中，你進行的添加列，刪除列，插入，更新等任何操作都會被當做操作消息存儲在非葉節點上。由于操作只是被簡單地存儲在緩存或者任何次級索引緩存(secondary index buffer)中，所以，所有的操作都會被迅速執行結束。

    當某一個節點的緩存滿了之后，這些操作消息會依次從根節點，經過非葉節點，向葉節點進行傳遞。葉節點仍然存儲著真實數據。當進行讀時，讀操作會考慮查詢路徑節點上的所有操作消息來獲取真實的數據狀態。但是由于tokudb會盡力將所有非葉節點緩存在內存中，所以這一過程也很快。

?tokubd中的block最大可以達到4MB，而不是InnoDB中的16KB。這樣的大小可以允許一次I/O操作時加載或寫回更多的數據，這也有助于一次壓縮更多數據來減少磁盤上數據的存儲大小。

    因此，tokudb強調借助更大的block大小能夠實現更好的數據壓縮和更少的磁盤I/O。tokudb宣稱它們的存儲引擎比InnoDB更快,提供比InnoDB更快的讀寫吞吐,并且tokudb也宣稱自己有更少的碎片(fragmentation)問題，它也支持多集群索引等。下圖是benchmark的相關統計圖：

 

?只有你系統中的benchmark可以幫助你判斷正確的數據點和需求解決方案。但是MySQL的存儲引擎會持續地不斷改進和支持新出現的需求。LSM樹是為了高寫入場景的系統，然而B樹是為了傳統的場景應用。Fractal樹的索引改進了B樹索引存在的一些缺陷。因此，未來會不斷地出現技術上的革新，包括數據庫存儲技術，硬件，磁盤驅動和操作系統，讓我們拭目以待。