“MySQL效能最佳化” – InfoQ & Baidu技術沙龍小記

上周六去參加了一次InfoQ舉辦的百度技術沙龍。主題是關於MySQL的。當天到場了不少人，有些出乎我意料之外，也許是因為免費的吧：）

一共有兩個演講嘉賓，第一個來自百度，主要介紹了百度在SSD/Flash上做的工作，第二個來自terradata，主題是關於spatial database的。坦率的說，第一個演講非常的棒，看得出來百度在SSD方面做了很多的工作，講述得也很詳細。第二個則有些像白開水，平淡無味，而且東西比較淺。

重點寫一下第一個講座的心得。

 

其實思想很簡單，既然是想在SSD上做文章，自然就是想利用SSD特有的效能優勢。SSD有什麼好處呢，演講嘉賓舉了好些資料，簡單的說，SSD對於隨機讀支援得很好，隨機寫效能一般，追加寫（append write）效能不錯。所以用SSD，要麼應用情境切合SSD的優勢，要麼，從架構上改變應用情境的IO模式，使其適合SSD的特點。

對於Mysql，對於資料庫來說，肯定是有大量的讀操作，這點用SSD當然會有很大的效能提高，但另一方面，很多時候也會面臨大量的寫操作，尤其是隨機寫，這種情況就不是很適用於SSD了。所以，百度對Mysql的儲存引擎Innodb寫了一個3000行的patch。這個patch幹什麼用呢，說白了就一句話，將隨機寫轉變為追加寫。

那麼，這事怎麼做呢？

由於當時的PPT還沒有放出來，所以我只是根據自己的記憶畫了個草圖，當然架構中的很多部分我都忽略掉了。湊合著看吧。

當mysql需要對資料庫的資料進行寫操作時，它並不是直接寫原來的data file，而是把寫好的page放在記憶體中，當記憶體中攢滿了幾個page後，它就將這些page組織成一個block，將這個block以append write的方式寫入到另一個cache file中。這一步很重要，因為它將本來是隨機寫入原始data file中的操作編程了對cache file的追加寫。

再看讀資料，記憶體中會維護一份page mapping，這樣當database需要讀某個page的資料的時候，它會寫在page mapping中尋找這個page是在data file還是在cache file中，然後再從相應的file中將資料取出來。雖然cache file中的資料是非常淩亂的組織，但由於SSD的隨機讀效能很好，所以這一點就不成問題。

最後，cache file在某個時刻要合并到原始的data file中。這一步其實會產生大量的隨機寫。但是，系統可以通過調度和控制，找到一個系統負荷很小的時刻來執行這個merge操作，比如深夜。這樣，就避免了大量的隨機寫對系統的效能造成影響。

換個角度看，其實它並不是真正的將隨機寫變成了追加寫，而是暫時將隨機寫變成了追加寫，然後找到一個合適的時機將這些追加寫再變回為隨機寫。看起來似乎設計得也挺簡單的。但我相信，這個方案肯定也是經過了很多次的實驗和討論才能成型的。

 

另外，SSD另一個遭人詬病的地方是它的故障率。百度給出的一個指標是每周千分之二的故障，可以說這已經是很高了。會後我私下問是怎麼解決這個問題的。答案大體分為幾層，首先，在裝置層面，SSD本身會有一些容錯恢複機制，其次，可以採用raid方式進行容錯，最後，在分布式架構上設計容錯演算法。

 

-- END --