摘要

面試時，交流有關mysql索引問題時，發(fā)現(xiàn)有些人能夠濤濤不絕的說出B+樹和B樹，平衡二叉樹的區(qū)別，卻說不出B+樹和hash索引的區(qū)別。這種一看就知道是死記硬背，沒有理解索引的本質。本文旨在剖析這背后的原理，歡迎留言探討

問題

如果對以下問題感到困惑或一知半解，請繼續(xù)看下去，相信本文一定會對你有幫助

• mysql 索引如何實現(xiàn)
• mysql 索引結構B+樹與hash有何區(qū)別。分別適用于什么場景
• 數(shù)據(jù)庫的索引還能有其他實現(xiàn)嗎
• redis跳表是如何實現(xiàn)的
• 跳表和B+樹，LSM樹有和區(qū)別呢

解析

首先為什么要把mysql索引和redis跳表放在一起討論呢，因為他們解決的都是同一種問題，用于解決數(shù)據(jù)集合的查找問題，即根據(jù)指定的key，快速查到它所在的位置（或者對應的value）

當你站在這個角度去思考問題時，還會不知道B+樹索引和hash索引的區(qū)別嗎

數(shù)據(jù)集合的查找問題

現(xiàn)在我們將問題領域邊界劃分清楚了，就是為了解決數(shù)據(jù)集合的查找問題。這一塊需要考慮哪些問題呢

1. 需要支持哪些查找方式，單key/多key/范圍查找，
2. 插入/刪除效率
3. 查找效率（即時間復雜度）
4. 存儲大?。臻g復雜度）

我們看下幾種常用的查找結構

hash

hash是key,value形式，通過一個散列函數(shù)，能夠根據(jù)key快速找到value

B+樹

B+樹是在平衡二叉樹基礎上演變過來，為什么我們在算法課上沒學到B+樹和跳表這種結構呢。因為他們都是從工程實踐中得到，在理論的基礎上進行了妥協(xié)。

B+樹首先是有序結構，為了不至于樹的高度太高，影響查找效率，在葉子節(jié)點上存儲的不是單個數(shù)據(jù)，而是一頁數(shù)據(jù)，提高了查找效率，而為了更好的支持范圍查詢，B+樹在葉子節(jié)點冗余了非葉子節(jié)點數(shù)據(jù)，為了支持翻頁，葉子節(jié)點之間通過指針連接。

跳表

跳表是在鏈表的基礎上進行擴展的，為的是實現(xiàn)redis的sorted set數(shù)據(jù)結構。 level0: 是存儲原始數(shù)據(jù)的，是一個有序鏈表，每個節(jié)點都在鏈上 level0+: 通過指針串聯(lián)起節(jié)點，是原始數(shù)據(jù)的一個子集，level等級越高，串聯(lián)的數(shù)據(jù)越少，這樣可以顯著提高查找效率，

總結

對LSM結構感興趣的可以看下cassandra vs mongo (1)存儲引擎

cassandra vs mongo (1)存儲引擎

概括

存儲引擎：

B-Tree

緩存管理

緩存管理的核心在于置換算法，置換算法常見的有FIFO（First In First Out），LRU(Least Recently Used)。關系型數(shù)據(jù)庫在LRU的基礎上，進行了改進，主要使用LIRS(Low Inter-reference Recency Set)
將緩存分為兩級，第一次采用LRU，最近被使用到的數(shù)據(jù)會進第一級，如果數(shù)據(jù)在較短時間內被訪問了兩次或以上，則成為熱點數(shù)據(jù)，進入第二級。避免了進行全表掃描的時候，可能會將緩存中的大量熱點數(shù)據(jù)替換掉。

LSM

Log-Structured Merge Tree:結構化合并樹，核心思想就是不將數(shù)據(jù)立即從內存中寫入到磁盤，而是先保存在內存中，積累了一定量后再刷到磁盤中

LSM VS B-Tree

LSM在B-Tree的基礎上為了獲取更好的寫性能而犧牲了部分的讀性能，同時利用其它的實現(xiàn)來彌補讀性能，比如boom-filter.

1.寫

B樹的寫入，是首先找到對應的塊位置，然后將新數(shù)據(jù)插入。隨著寫入越來越多，為了維護B樹結構，節(jié)點得分裂。這樣插入數(shù)據(jù)的隨機寫概率就會增大，性能會減弱。

LSM 則是在內存中形成小的排好序的樹，然后flush到磁盤的時候不斷的做merge.因為寫入都是內存寫，不寫磁盤，所以寫會很高效。

2.讀

B樹從根節(jié)點開始二分查詢直到葉子節(jié)點，每次讀取一個節(jié)點，如果對應的頁面不在內存中，則讀取磁盤，緩存數(shù)據(jù)。

LSM樹整個結構不是有序的，所以不知道數(shù)據(jù)在什么地方，需要從每個小的有序結構中做二分查詢，找到了就返回，找不到就繼續(xù)找下一個有序結構。所以說LSM犧牲了讀性能。但是LSM之所以能夠作為大規(guī)模數(shù)據(jù)存儲系統(tǒng)在于讀性能可以通過其他方式來提高，比如讀取性能更多的依賴于內存/緩存命中率而不是磁盤讀取。

Cassandra

Cassandra是一個寫性能優(yōu)于讀性能的NoSql數(shù)據(jù)庫，寫性能好一個原因在于選擇了LSM存儲引擎。

Mongo

MMAPv1

Mongo 3.2以前默認使用MMAPv1存儲引擎，是基于B-Tree類型的。

邊界(padding)

MMAPv1 存儲引擎使用一個叫做”記錄分配”的過程來為document存儲分配磁盤空間。MongoDB與Cassandra不同的是，需要去更新原有的document。如果原有的document空間不足，則需要將這個document移動到新的位置，更新對應的index。這樣就會導致一些不必要的更新，和數(shù)據(jù)碎片。

為了避免出現(xiàn)上述情況，就有了邊界的概念，就是為document預分配空間。但是這樣就有可能造成資源的浪費。mongo 按照64M,128M,256M…2G的2的冥次方遞增策略預分配，最大2G。在數(shù)據(jù)量小的情況下問題并不明顯，但是當達到2G時，磁盤占用量大的問題就出來了。

同樣這一點和關系型數(shù)據(jù)庫也不一樣，關系型數(shù)據(jù)庫對于長記錄數(shù)據(jù)會分開存儲。

鎖

MMAPv1使用collection級別的鎖，即一個collecion增，刪，改一次只能有一個。在并發(fā)操作時，就會造成等待。

WiredTiger

3.2及其以后的默認存儲引擎,同樣是基于B-Tree的。采用了lock-free,風險指針等并發(fā)技術，使得在多核機器上工作的更好。

鎖級別為document。并且引入了compression，減少了磁盤占用。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。

最新評論