存儲引擎原理

數據庫存儲引擎是數據庫底層軟件組織，數據庫管理系統（DBMS）使用數據引擎進行創建、查詢、更新和刪除數據。不同的存儲引擎提供不同的存儲機制、索引技巧、鎖定水平等功能，使用不同的存儲引擎，還可以 獲得特定的功能。現在許多不同的數據庫管理系統都支持多種不同的數據引擎。MySQL的核心就是存儲引擎。

存儲引擎的選擇

不同的存儲引擎都有各自的特點，以適應不同的需求，如下表所示：

功 能	MYISAM	Memory	InnoDB	Archive
存儲限制	256TB	RAM	64TB	None
支持事物	No	No	Yes	No
支持全文索引	Yes	No	No	No
支持數索引	Yes	Yes	Yes	No
支持哈希索引	No	Yes	No	No
支持數據緩存	No	N/A	Yes	No
支持外鍵	No	No	Yes	No

如果要提供提交、回滾、崩潰恢復能力的事物安全（ACID兼容）能力，並要求實現並發控制，InnoDB是一個好的選擇

如果數據表主要用來插入和查詢記錄，則MyISAM引擎能提供較高的處理效率

如果只是臨時存放數據，數據量不大，並且不需要較高的數據安全性，可以選擇將數據保存在內存中的Memory引擎，MySQL中使用該引擎作為臨時表，存放查詢的中間結果

如果只有INSERT和SELECT操作，可以選擇Archive，Archive支持高並發的插入操作，但是本身不是事務安全的。Archive非常適合存儲歸檔數據，如記錄日志信息可以使用Archive

使用哪一種引擎需要靈活選擇，一個數據庫中多個表可以使用不同引擎以滿足各種性能和實際需求，使用合適的存儲引擎，將會提高整個數據庫的性能

 

存儲引擎查看

mysql給開發者提供了查詢存儲引擎的功能，我這里使用的是MySQL5.1，可以使用：

SHOW ENGINES

命令來查看MySQL使用的引擎，命令的輸出為（我用的Navicat Premium）：

 

看到MySQL給用戶提供了這么多存儲引擎，包括處理事務安全表的引擎和出來了非事物安全表的引擎。

如果要想查看數據庫默認使用哪個引擎，可以通過使用命令：

SHOW VARIABLES LIKE 'storage_engine';

來查看，查詢結果為：

在MySQL中，不需要在整個服務器中使用同一種存儲引擎，針對具體的要求，可以對每一個表使用不同的存儲引擎。Support列的值表示某種引擎是否能使用：YES表示可以使用、NO表示不能使用、DEFAULT表示該引擎為當前默認的存儲引擎 。下面來看一下其中幾種常用的引擎。

 

InnoDB存儲引擎

InnoDB是事務型數據庫的首選引擎，支持事務安全表（ACID），支持行鎖定和外鍵，上圖也看到

了，InnoDB是默認的MySQL引擎。InnoDB主要特性有：

 

1、InnoDB給MySQL提供了具有提交、回滾和崩潰恢復能力的事物安全（ACID兼容）存儲引擎。InnoDB鎖定在行級並且也在SELECT語句中提供一個類似Oracle的非鎖定讀。這些功能增加了多用戶部署和性能。在SQL查詢中，可以自由地將InnoDB類型的表和其他MySQL的表類型混合起來，甚至在同一個查詢中也可以混合

 

2、InnoDB是為處理巨大數據量的最大性能設計。它的CPU效率可能是任何其他基於磁盤的關系型數據庫引擎鎖不能匹敵的

 

3、InnoDB存儲引擎完全與MySQL服務器整合，InnoDB存儲引擎為在主內存中緩存數據和索引而維持它自己的緩沖池。InnoDB將它的表和索引在一個邏輯表空間中，表空間可以包含數個文件（或原始磁盤文件）。這與MyISAM表不同，比如在MyISAM表中每個表被存放在分離的文件中。InnoDB表可以是任何尺寸，即使在文件尺寸被限制為2GB的操作系統上

 

4、InnoDB支持外鍵完整性約束，存儲表中的數據時，每張表的存儲都按主鍵順序存放，如果沒有顯示在表定義時指定主鍵，InnoDB會為每一行生成一個6字節的ROWID，並以此作為主鍵

 

5、InnoDB被用在眾多需要高性能的大型數據庫站點上

InnoDB不創建目錄，使用InnoDB時，MySQL將在MySQL數據目錄下創建一個名為ibdata1的10MB大小的自動擴展數據文件，以及兩個名為ib_logfile0和ib_logfile1的5MB大小的日志文件

 

MyISAM存儲引擎

MyISAM基於ISAM存儲引擎，並對其進行擴展。它是在Web、數據倉儲和其他應用環境下最常使用的存儲引擎之一。MyISAM擁有較高的插入、查詢速度，但不支持事物。MyISAM主要特性有：

 

1、大文件（達到63位文件長度）在支持大文件的文件系統和操作系統上被支持

2、當把刪除和更新及插入操作混合使用的時候，動態尺寸的行產生更少碎片。這要通過合並相鄰被刪除的塊，以及若下一個塊被刪除，就擴展到下一塊自動完成

3、每個MyISAM表最大索引數是64，這可以通過重新編譯來改變。每個索引最大的列數是16

4、最大的鍵長度是1000字節，這也可以通過編譯來改變，對於鍵長度超過250字節的情況，一個超過1024字節的鍵將被用上

5、BLOB和TEXT列可以被索引

6、NULL被允許在索引的列中，這個值占每個鍵的0~1個字節

7、所有數字鍵值以高字節優先被存儲以允許一個更高的索引壓縮

8、每個MyISAM類型的表都有一個AUTO_INCREMENT的內部列，當INSERT和UPDATE操作的時候該列被更新，同時AUTO_INCREMENT列將被刷新。所以說，MyISAM類型表的AUTO_INCREMENT列更新比InnoDB類型的AUTO_INCREMENT更快

9、可以把數據文件和索引文件放在不同目錄

10、每個字符列可以有不同的字符集

11、有VARCHAR的表可以固定或動態記錄長度

12、VARCHAR和CHAR列可以多達64KB

使用MyISAM引擎創建數據庫，將產生3個文件。文件的名字以表名字開始，擴展名之處文件類型：frm文件存儲表定義、數據文件的擴展名為.MYD（MYData）、索引文件的擴展名時.MYI（MYIndex）

 

MEMORY存儲引擎

MEMORY存儲引擎將表中的數據存儲到內存中，未查詢和引用其他表數據提供快速訪問。MEMORY主要特性有：

1、MEMORY表的每個表可以有多達32個索引，每個索引16列，以及500字節的最大鍵長度

2、MEMORY存儲引擎執行HASH和BTREE縮影

3、可以在一個MEMORY表中有非唯一鍵值

4、MEMORY表使用一個固定的記錄長度格式

5、MEMORY不支持BLOB或TEXT列

6、MEMORY支持AUTO_INCREMENT列和對可包含NULL值的列的索引

7、MEMORY表在所由客戶端之間共享（就像其他任何非TEMPORARY表）

8、MEMORY表內存被存儲在內存中，內存是MEMORY表和服務器在查詢處理時的空閑中，創建的內部表共享

9、當不再需要MEMORY表的內容時，要釋放被MEMORY表使用的內存，應該執行DELETE FROM或TRUNCATE TABLE，或者刪除整個表（使用DROP TABLE）

 

1、Hash存儲引擎

代表數據庫：redis、memcache等

通常也常見於其他存儲引擎的查找速度優化上。 Hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像B-Tree 索引需要從根節點到枝節點，最后才能訪問到頁節點這樣多次的IO訪問，所以 Hash 索引的查詢效率要遠高於 B-Tree 索引。雖然 Hash 索引效率高，但是 Hash 索引本身由於其特殊性也帶來了很多限制和弊端。

這里列舉缺點：

（1）Hash 索引僅僅能滿足"=","IN"和"<=>"查詢，不能使用范圍查詢。
（2）Hash 索引無法被用來避免數據的排序操作。
（3）Hash 索引不能利用部分索引鍵查詢。
(4）Hash 索引在任何時候都不能避免表掃描。
Hash碰撞，就是鏈式掃描：
由於不同索引鍵存在相同 Hash 值，所以即使取滿足某個 Hash 鍵值的數據的記錄條數，也無法從 Hash索引中直接完成查詢，還是要通過訪問表中的實際數據進行相應的比較，並得到相應的結果。
（5）Hash 索引遇到大量Hash值相等的情況后性能並不一定就會比B-Tree索引高。

2、B樹存儲引擎

代表數據庫：MongoDB、mysql(基本上關系型數據庫)等

 

還有一種算是B樹存儲引擎：COLA樹（CacheObliviousBTree）

代表數據庫：tokudb

為了如何讓B樹更有效的執行，他們提出了一個緩存忘卻CacheOblivious算法，該算法在不需要明確知道存儲器層次中數據傳輸規模的情況下，也可以高效的工作。更多請參見：https://en.wikipedia.org/wiki/Cache-oblivious_algorithm。

說個大家熟悉的名稱TokuMX : 目前非常流行的NoSQL數據庫MongoDB的底層替換成與TokuDB同樣的存儲引擎[ ToKuMx]，達到了非常好的效 果

3、LSM樹（Log-Structured Merge Tree）存儲引擎

代表數據庫：nessDB、leveldb、hbase等

核心思想的核心就是放棄部分讀能力，換取寫入的最大化能力。LSM Tree ，這個概念就是結構化合並樹的意思，它的核心思路其實非常簡單，就是假定內存足夠大，因此不需要每次有數據更新就必須將數據寫入到磁盤中，而可以先將最新的數據駐留在磁盤中，等到積累到最后多之后，再使用歸並排序的方式將內存內的數據合並追加到磁盤隊尾(因為所有待排序的樹都是有序的，可以通過合並排序的方式快速合並到一起)。

日志結構的合並樹（LSM-tree）是一種基於硬盤的數據結構，與B-tree相比，能顯著地減少硬盤磁盤臂的開銷，並能在較長的時間提供對文件的高速插入（刪除）。然而LSM-tree在某些情況下，特別是在查詢需要快速響應時性能不佳。通常LSM-tree適用於索引插入比檢索更頻繁的應用系統。Bigtable在提供Tablet服務時，使用GFS來存儲日志和SSTable，而GFS的設計初衷就是希望通過添加新數據的方式而不是通過重寫舊數據的方式來修改文件。而LSM-tree通過滾動合並和多頁塊的方法推遲和批量進行索引更新，充分利用內存來存儲近期或常用數據以降低查找代價，利用硬盤來存儲不常用數據以減少存儲代價。

磁盤的技術特性:對磁盤來說，能夠最大化的發揮磁盤技術特性的使用方式是:一次性的讀取或寫入固定大小的一塊數據，並盡可能的減少隨機尋道這個操作的次數。

 

LSM和Btree差異就要在讀性能和寫性能進行舍和求。在犧牲的同事，尋找其他方案來彌補。

1、LSM具有批量特性，存儲延遲。當寫讀比例很大的時候（寫比讀多），LSM樹相比於B樹有更好的性能。因為隨着insert操作，為了維護B樹結構，節點分裂。讀磁盤的隨機讀寫概率會變大，性能會逐漸減弱。 多次單頁隨機寫，變成一次多頁隨機寫,復用了磁盤尋道時間，極大提升效率。

2、B樹的寫入過程:對B樹的寫入過程是一次原位寫入的過程，主要分為兩個部分，首先是查找到對應的塊的位置，然后將新數據寫入到剛才查找到的數據塊中，然后再查找到塊所對應的磁盤物理位置，將數據寫入去。當然，在內存比較充足的時候，因為B樹的一部分可以被緩存在內存中，所以查找塊的過程有一定概率可以在內存內完成，不過為了表述清晰，我們就假定內存很小，只夠存一個B樹塊大小的數據吧。可以看到，在上面的模式中，需要兩次隨機尋道（一次查找，一次原位寫），才能夠完成一次數據的寫入，代價還是很高的。

3、LSM Tree放棄磁盤讀性能來換取寫的順序性，似乎會認為讀應該是大部分系統最應該保證的特性，所以用讀換寫似乎不是個好買賣。但別急，聽我分析一下。

a、內存的速度遠超磁盤，1000倍以上。而讀取的性能提升，主要還是依靠內存命中率而非磁盤讀的次數

b、寫入不占用磁盤的io，讀取就能獲取更長時間的磁盤io使用權，從而也可以提升讀取效率。例如LevelDb的SSTable雖然降低了了讀的性能，但如果數據的讀取命中率有保障的前提下，因為讀取能夠獲得更多的磁盤io機會，因此讀取性能基本沒有降低，甚至還會有提升。而寫入的性能則會獲得較大幅度的提升，基本上是5~10倍左右。

下面說說詳細例子:

LSM Tree弄了很多個小的有序結構，比如每m個數據，在內存里排序一次，下面100個數據，再排序一次……這樣依次做下去，我就可以獲得N/m個有序的小的有序結構。

在查詢的時候，因為不知道這個數據到底是在哪里，所以就從最新的一個小的有序結構里做二分查找，找得到就返回，找不到就繼續找下一個小有序結構，一直到找到為止。

 

很容易可以看出，這樣的模式，讀取的時間復雜度是(N/m)*log2N 。讀取效率是會下降的。

這就是最本來意義上的LSM tree的思路。那么這樣做，性能還是比較慢的，於是需要再做些事情來提升，怎么做才好呢？

LSM Tree優化方式：

a、Bloom filter: 就是個帶隨即概率的bitmap,可以快速的告訴你，某一個小的有序結構里有沒有指定的那個數據的。於是就可以不用二分查找，而只需簡單的計算幾次就能知道數據是否在某個小集合里啦。效率得到了提升，但付出的是空間代價。

b、compact:小樹合並為大樹:因為小樹他性能有問題，所以要有個進程不斷地將小樹合並到大樹上，這樣大部分的老數據查詢也可以直接使用log2N的方式找到，不需要再進行(N/m)*log2n的查詢了