April 2014 Flash-aware MySQL フラッシュが MySQL を変える Takeshi Hasegawa Senior Sales Engineer APAC Japan Fusion-io

(1)

Flash-aware MySQL

〜フラッシュが

MySQLを変える〜

(2)

不揮発メモリ

_{(NVM)の登場}

▸ フラッシュ

(NAND)

• デバイスあたり数百

GB〜 10TBの容量

• フラッシュ技術のトレンド

▸ 大容量化

▸ GB単価コスト↓

▸ 書き込み回数の減少

▸ セルの多値化（

SLC→MLC→3BPC）

• 10万〜100万IOPS, GB/s級の帯域幅

▸ その他の不揮発メモリ技術（

PCM/MRAM/STT）

▸ 現時点では開発中のメモリ技術

(3)

なぜフラッシュを使うのか

_?

▸ I/O特性がデータベース用途に

適している

• 低レイテンシ、

QDの低いI/Oでも高性能

• ワークロードの種類を問わず

性能が高い

ü

 

シーケンシャルワークロード

ü

 

ランダムワークロード

ü

 

様々なブロックサイズ

▸ 容量

▸ IOPS

▸ IO単価

4TB

3TB

150 200,000

$$$$

¢¢¢¢

(4)

フラッシュの利用方法の遷移

フラッシュ＋ディスクディスクとしてのフラッシュフラッシュとしてのフラッシュメモリとしてのフラッシュ

フラッシュの特性を意識した実装

(5)

ディスクとしてのフラッシュ

_{: そのスピードにチューニング}

▸ 過去数年間の取り組みにより

大幅な性能向上を達成

▸ データ配置の最適化、

NOOPスケジューラ、

シークなしメディアへの最適化、

並列度の最適化

▸ ブロック

I/Oサブシステムの

高速化

▸ 高速なファイルシステムの探求

(6)

マルチインスタンス

_{MySQL: IOPS性能を絞り出す}

Instances

1

2

4 T

hro

ug

hp

ut

, N

O

T

/1

0se

c

0 4000 6000 8000 10000 12000

Fusion-io, 48 threads, 2400W – 64GB BP

4810 8788 11952 2000

(7)

フラッシュとしてのフラッシュ

_{: ただのディスクとは違う}

メトリック

ハードディスク

フラッシュメモリ

リード／ライト性能

リード／ライト、ほぼ対称

リード／ライト性能が非対称。

イレースという新たな操作が

登場

シーケンシャル／ランダムの

性能傾向

100倍の性能差。

ヘッドの動作を想定した

I/Oスケジューリング

〜10倍の性能差。

メモリ素子にはヘッド動作なし

ブロックのリマッピング、

バックグラウンドでの処理

極めて少ない

ログ構造のファイルシステムの

ように、定常的に発生

書き込み量の限界

ほぼ無し

制限あり

秒間あたりのI/O回数（IOPS）

100回〜1,000回／秒

10万回〜100万回／秒

レイテンシー（応答遅延）

10ミリ秒台

10〜100マイクロ秒台

(8)

(9)

“Flash-aware” スタックの構成

フラッシュストレージ –I/O と

新たなプリミティブ

(アトミックライト

、

PTRIMなど)

ファイルシステム

(XFS, Ext4, Btrfs,

NVMFS)

(10)

ダブルライト／アトミックライトの比較

従来の

_{MySQLのライト処理}

アトミックライト対応版

_MySQL

のライト処理

Page C Page B Page A バッファ DRAM バッファ SSD (もしくはHDD) データベース DBサーバ Page C Page B Page A Page C Page B Page A Page C Page B Page A アプリケーションがページA,B,Cを更新する 1 MySQLは更新されたページをバッファメモリにコピー 2 MySQLはダブルライトバッファに書き込む 3 ステップ3が完了してから、MySQLは表領域に書き込みを開始する 4 ioMemory データベース Page C Page B Page A Page C Page B Page A アプリケーションがページA,B,Cを更新する 1 MySQLは更新されたページをバッファメモリにコピー 2 MySQLはダブルライトを省略し、表領域に直接書き込みデータの整合性は下位デバイスの機能により担保される 3 DBサーバ Page C Page B Page A DRAM バッファ

(11)

MySQL + アトミックライトの利点

ダブルライトを無効化（

Non-ACID）

ダブルライト

（

ACID

）

従来の場合

アトミックライトを利用する場合

ACID特性を維持したまま

二倍の性能を実現

アトミックライト（

ACID）

•  アトミックライトによりデバイス性能の99%を利用可能

•  デバイスの書き込み耐用期間が２倍に

(12)

0 20 40 60 80 100 120 140 160 180 200 1 107 213 319 425 531 637 743 849 955 ₁₀₆₁ ₁₁67 ₁₂₇₃ ₁₃₇₉ ₁₄₈₅ ₁₅₉₁ ₁₆₉₇ ₁₈₀₃ ₁₉₀₉ ₂₀₁₅ ₂₁₂₁ ₂₂₂₇ ₂₃₃₃ ₂₄₃₉ ₂₅₄₅ ₂₆₅₁ ₂₇₅₇ ₂₈₆₃ ₂₉₆₉ ₃₀₇₅ ₃₁₈₁ ₃₂₈₇ ₃₃₉₃ ₃₄₉₉ Mi lli se co n d s Seconds

Sysbench 99% Latency

OLTP workload

XFS DoubleWrite

DirectFS Atomic

アトミックライト

_{: トランザクションのレイテンシー改善}

トランザクションのレイテンシーが

2分の1〜4分の1まで短縮

Atomic Writes

(13)

NVM コンプレッション

▸ フラッシュデバイスが持つ、内部的な

「シンプロビジョニング」動作を活用

▸ データファイル上の不要ブロックを

TRIM(UMMAP)しホール（スパース）化

▸ フラッシュ処理のマルチスレッド化、

アトミックライトによりレイテンシーを削減

▸ プラグイン式で置き換え可能な

圧縮アルゴリズム

ioMemory VSL

NVMFS

MySQL

(14)

NVMコンプレッションの性能オーバーヘッドはごく僅か

100%

20%

90%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Uncompressed

Row Compression

NVM-Compression

(15)

NVMコンプレッションの性能オーバーヘッドはごく僅か

0 5000 10000 15000 20000 25000 30000 T ime 130 260 390 520 650 780 910 ₁₀₄₀ ₁₁70 ₁₃₀₀ ₁₄₃₀ ₁₅₆₀ ₁₆₉₀ ₁₈₂₀ ₁₉₅₀ ₂₀₈₀ ₂₂₁₀ ₂₃₄₀ ₂₄₇₀ ₂₆₀₀ ₂₇₃₀ ₂₈₆₀ ₂₉₉₀ ₃₁₂₀ ₃₂₅₀ ₃₃₈₀ ₃₅₁₀

New Order TX

TPC-C like workload

1,000 warehouses - 75GB DRAM

MySQL uncompressed

MySQL compression

Fusion-io Compression

Time

(16)

圧縮により書き込み減少

_{→容量の有効利用、長寿命化}

Row-comp

Page-comp

49.0%

58.5%

44.0% 46.0% 48.0% 50.0% 52.0% 54.0% 56.0% 58.0% 60.0%

%

im

p

ro

ve

m

en

t

Vs. Uncompressed *

*For LinkBench with lz77. Comparable results with lz4.

•  従来のInnoDBストレージ

エンジンの行ベース圧縮を

超える高圧縮率

•  デバイスの耐用期間が

アトミックライトと組み合わせで

最大４倍に

(17)

ファイルシステムからのミドルウェア高速化

POSIXインターフェイス

動作

fallocate(offset, len)

既存ファイル／テーブルスペースの容量追加、

プリアロケーション

fallocate(

PUNCH_HOLE

)

アンマップ（

Punch Hole）操作。

デバイスに対し

_{Persistent TRIMコマンド発行}

io_submit()

非同期

_{I/Oで透過的にアトミックライトを実現}

NVM コンプレッションは、POSIXインターフェイスで実現

(18)

NVMFS ーフラッシュメモリのためのファイルシステム

▸ Non Volatile Memory FileSystem

（不揮発メモリ用ファイルシステム）

▸ Fusion-ioが開発した、POSIX準拠のファイルシステム

▸ 利点

• 大きなファイルのプリアロケーションを効率的に実現

• ファイルシステムを使い続けても、

”断片化”は発生しない

• ファイルシステム経由でもデバイスの

I/O性能が落ちづらい

• アトミックライトやファイル内

TRIMなどの機能を利用可能に

(19)

(20)

(21)

“Flash-aware MySQL” by Oracle

▸ アトミックライト対応

• Oracle MySQL >= 5.7.4

▸ NVM コンプレッション対応

• Oracle MySQL – labs release (http://labs.mysql.com/)

(22)

fusionio.com

|

DELIVERING THE WORLD’S DATA. FASTER.

April 2014 Flash-aware MySQL フラッシュが MySQL を変える Takeshi Hasegawa Senior Sales Engineer APAC Japan Fusion-io

Flash-aware MySQL

〜フラッシュが

MySQLを変える〜

不揮発メモリ

(NVM)の登場

▸

フラッシュ

(NAND)

•

デバイスあたり数百

GB〜 10TBの容量

•

フラッシュ技術のトレンド

▸

大容量化

▸

GB単価コスト↓

▸

書き込み回数の減少

▸

セルの多値化（

SLC→MLC→3BPC）

•

10万〜100万IOPS, GB/s級の帯域幅

▸

その他の不揮発メモリ技術（

PCM/MRAM/STT）

▸

現時点では開発中のメモリ技術

なぜフラッシュを使うのか

?

▸

I/O特性がデータベース用途に

適している

•

低レイテンシ、

QDの低いI/Oでも高性能

•

ワークロードの種類を問わず

性能が高い

ü

シーケンシャル ワークロード

ü

ランダム ワークロード

ü

様々なブロックサイズ

▸

容量

▸

IOPS

▸

IO単価

4TB

3TB

150

200,000