【MySQL】MyRocks 漫談

一 前言 
   最近一兩年，資料庫技術尤其是MySQL方面的發展可謂百花齊放，TokuDB，MyRocks ，MySQL 5.7 GA,MySQL 8.0 doc release 其軟體也在開發當中，ALiSQL 開源。其中有功能上的改進的，也有針對Innodb 本身缺陷(主要是儲存空間方面的)做最佳化的，作為資料庫技術方面的從業者多少有些應接不暇。結合今年ACMUG 技術大會上的技術分享，Percona官方對MyRocks的表態，阿里在技術上的研究，落地來看，可以明顯感覺到Myrocks是一種發展趨勢。本文將對MyRocks做一個簡單的瞭解。
二 MyRocks 是什麼
   是FB基於levelDB(使用LSM 組織資料結構)開發並且開源出來的資料庫儲存引擎，支援通用的MySQL 讀寫,鎖機制,MVCC,事務(目前僅支援RR,RC)，主從複製。目前已經在FB的使用者中心使用。
三 MyRocks 解決什麼問題
   這需要先從FB的業務模式來說，fb 作為全球最大的sns網站，其資料量巨大，需要儲存資料的伺服器想必也是數十萬或者百萬級別的，這些都是money。(同樣也適用於阿里，騰訊這樣體量的公司)為了應對未來儲存空間的增長和節約伺服器，fb開發了此款儲存引擎。為啥Innodb 不滿足需求呢? 熟悉Innodb儲存引擎的朋友知道Innodb是基於B+Tree 實現的資料儲存，其預設的資料塊大小是16k，目前支援可調節的block_size. 但是依然存在如下問題：
 1 寫入放大.
    B*tree要修改資料時，就需要將新入資料下面的資料重新排位，特別是當寫入的資料排在較高的位置時，需要大量的移位操作才能完成寫入。而且InnoDB 讀寫訪問資料的最小邏輯單位是資料塊,隨機寫的情況下，修改N行，可能要修改N個資料塊。
    MyRocks的寫操作以append only的方式。根據LSM Tree的演算法，其將隨機寫轉化為順序寫，寫操作只需更新記憶體，記憶體中的資料以塊資料形式刷到磁碟，是順序的IO操作，另外磁碟檔案定期的合併操作，也將帶來磁碟IO操作。
具體實現方式如下：
 2 磁碟空間碎片
   B*tree分裂導致page內有較多空閒空間，總體空間利用率不高。儘管Innodb提供壓縮的方式，但是壓縮以block為單位，也會造成浪費。比如總共16k的資料，壓縮到5k 但是儲存磁碟依然需要8k 的空間。
 3 RocksDB對齊開銷小:SST file (預設2MB)需要對齊，但遠大於4k, RocksDB_block_size(預設4k) 不需要對齊,因此對齊浪費空間較少。
 
四 有哪些限制
  1 MyRocks目前只支援兩種隔離級別，RC和RR。
  2 鎖機制不健全 不支援gap lock
  3 目前階段Innodb和Myrocks 混用不穩定，Percona 在做合併的工作，ACMUG大會上的Percona工程師表示已經測試了80%的場景。
  4 binlog與RocksDB之間沒有xa，異常crash可能丟資料。所以，MyRocks一般開啟semi-sync.
  5 讀效能上相對Inndb 比較弱，不支援MRR ，範圍查詢比較慢。
五 總結
  目前而言公開在生產環境使用MyRocks儲存引擎的只有FB和阿里和阿里雲RDS在技術調研，相信其他同行也在做技術調研，期待未來有更多的生產實踐。本文僅僅算是對Myrocks一個粗淺的認知，要掌握MyRocks，知其然，知其所以然。推薦大家去看看LSM Tree的演算法
 【推薦 其中的文件】
LSM Tree儲存組織結構介紹 
 
ACMUG大會MyRocks 介紹的PPT 【推薦】