Facebook 把 InnoDB 換成 MyRocks 的計畫

在「Migrating a database from InnoDB to MyRocks」這邊講到了 FacebookMySQL 的 InnoDB 換成 MyRocks 的計畫。

Facebook 已經大量導入全 Flash 的環境,於是現在 InnoDB (Compressed) 的情況類似於這樣:

可以看到空間是最大的問題 (Space-bound),而非 CPU 或是 I/O,這在純 Flash 的機器上還蠻有可能的,因為純 Flash 能提供的 I/O capacity 超高,加上 Facebook 把 MySQL 當作後端儲存設備而已,CPU 的使用量可以預期不高...

然後他們估算 MyRocks 可以省下一半的空間,於是有可能變成:

不過對於一般單位來說,這些前提就未必成立了... 但還是可以看到 Mark Callaghan 花不少力氣在調校一般性的效能,希望讓使用者多一點...

InnoDB 與 MyRocks 之間的取捨

MyRocks 的主要作者 Mark Callaghan 整理了一篇關於大台機器下,資料可以放到記憶體內的效能比較:「In-memory sysbench, a larger server and contention - part 1」。

這其實才是一般會遇到的情況:當事業夠大時,直接花錢買 1TB RAM + 數片 PCI-E SSD 的機器用錢換效能... (主要應該會在記憶體花不少錢,剛剛查了一下,現在白牌的 server 一台大約七十萬就可以擺平?兩台做 HA 也才一百四十萬,對有這個規模的單位來說通常不是大問題...)

而三種不同的 case 裡面,最後這個應該是最接近真實情況的:

可以看到 InnoDB 在幾乎所有項目都還是超越 MyRocks (只有 random-points 與 insert-only 輸)。

不知道後續的開發能量還會有多少... (因為 Facebook 的用法跟一般情況不一樣)

MyRocks 與 InnoDB 在 INSERT 效能的比較

MyRocksMark Callaghan 對 INSERT 效率整理出來的比較:「Insert benchmark, MyRocks and InnoDB」。

當資料比記憶體小的時候,InnoDB 效能比較好。但超過記憶體大小時就是 MyRocks 效能比較好。另外 InnoDB 在 MySQL 5.7 的效率比 5.6 好不少。

兩張圖來自相同資料,只是 x 軸不太一樣。

是從 16 台 client 裡面抽一台的量出來,這樣就可以解釋後面那段爬上來... (其他台跑完了,所以這台的 insert 速度變快了)

This is for data from one of the 16 clients rather than the global rate because my test script forgot to collect that.

While it is odd that the throughput rate for InnoDB 5.7 picks up at test end, that can occur if the thread I monitored ran longer than other threads and had less competition for HW resources near test end.

MyRocks 與 InnoDB 對於不同硬碟效能的差異

在「MyRocks: use less IO on writes to have more IO for reads」這邊有提到當使用 Disk Array、Slow SSD 與 Fast SSD 時效能 MyRocks 與 InnoDB 的效能差異。

可以看到當 I/O 層能提供的 IOPS capacity 愈高,MyRocks 與 InnoDB 之間的差異就愈低... 換句話說,RocksDB 對 IOPS 比較有效率的應用,這點在「Why is MyRocks more write-efficient than InnoDB?」這邊也可以看出一些說明 (不過這篇的 InnoDB 完全沒用 COMPRESSED)。

算是推銷... 不過可以持續關注看看 :o

Percona 宣佈支援 MyRocks (MySQL 上的 RocksDB engine)

RocksDBFacebookGoogle 放出的 LevelDB 改出來,然後被更多人接受並且投注資源的 library... (看兩邊的 GitHub 應該就會有感覺了)

而 Facebook 的人在改進後又花了不少力氣 porting 到 MySQL 上...

之前 Twitter 上就有看到不少消息,這次算是在 Percona 官方的 blog 上正式公佈要支援 MyRocks 的消息:「Announcing MyRocks in Percona Server for MySQL」。

依照目前的計畫次在明年 2017 的 Q1 放出 experimental build,依照 Percona 的品質慣例,應該是可以拿來在測試環境下跑的順順的 (在還沒有 heavy loading 的前提下):

We will provide the experimental builds of MyRocks in Percona Server in Q1 2017, and we encourage you to start testing and experimenting so we can quickly release a solid GA version.

文章下面的 comment 剛好有人提到 Percona 另外一個產品線 TokuDB,這兩個產品線重複的問題:

MyRocks seems pretty similar to TokuDB. They are both write-optimized. MyRocks uses LSM tree while TokuDB uses fractal tree.

How do the 2 compare? Which one would you recommend using?

之前被 Percona 買下的 TokuDB 跟 Facebook 所發展出來的 MyRocks 的產品重複性頗高 (都是為了寫入的部分最佳化)。應該還是因為 fractal treeLSM tree 成熟度造成的效能差異還是太明顯吧 (當然另外也跟後面公司投入的資源有關),讓 Percona 決定還是要支援 MyRocks,而不是全力推動自家買下的 TokuDB... (唔,變成阿斗了?)

不知道成熟後有沒有機會變成 InnoDB replacement...

Mark Callaghan 講最近的 MySQL 的行銷活動...

Mark Callaghan 這篇倒是沒提到什麼技術的東西,主要是講最近 MySQL 的兩大 conference,一個是 OracleOracle Open World,另外一個是 PerconaPercona Live Amsterdam 2016,然後用了 benchmarketing 這個酸酸的詞 XDDD:「Peak benchmarketing season for MySQL」。

裡面有些也很有趣的東西:

My joke is that each of these makes a different group happy: performance -> marketing, usability -> developers, manageability -> operations, availability -> end users, efficiency -> management.

另外提到了 RocksDB 建出來的 MyRocks 在 memory fit 時可能會比 InnoDB 還要好:

One last disclaimer. If you care about read-mostly/in-memory workloads then InnoDB is probably an excellent choice. MyRocks can still be faster than InnoDB for in-memory workloads. That is more likely when the bottleneck for InnoDB is page write-back performance. So write-heavy/in-memory can still be a winner for MyRocks.

這就有趣了,找個時間來測試看看...

MySQL 上 InnoDB 與 RocksDB 的差異

Mark Callaghan 在「MyRocks vs InnoDB with Linkbench over 7 days」這邊分析了 MySQL 上的兩個 engine 的差異,總結是大獲全勝:

  • InnoDB writes between 8X and 14X more data to SSD per transaction than RocksDB
  • RocksDB sustains about 1.5X more QPS
  • Compressed/uncompressed InnoDB uses 2X/3X more SSD space than RocksDB

但 InnoDB 的 engine 是 2000 年的設計 (16 年前),MyRocks 的 engine (RocksDB) 則是 2013 年的設計,不屬於同一個世代。

相較於與 InnoDB 對打,我更想看到的是與 TokuDB (2012 年的設計) 對打的結果。

兩個新的 engine 都有針對 SSD 的特性發展,可以看出資料結構與寫入的方式就很不一樣,而且一開始就是在多 CPU 多核環境下開發,相較於 InnoDB 是一路改的包袱來的輕鬆許多。