MySQL Cluster Casual Talksで使った資料です。Slideshareの表示ではフォントがおかしいのでダウンロードして使ってください。

1. カジュアルに
MySQL Cluster を
使ってみよう！
@MySQL Cluster Casual Talks 2013
奥野 幹也
@nippondanji
mikiya (dot) okuno (at) gmail (dot) com

2. 免責事項
●
本プレゼンテーションにおいて示されている見解は、
私自身の見解であって、オラクル・コーポレーション
の見解を必ずしも反映したものではありません。ご
了承ください。

3. 自己紹介
●
MySQL サポートエンジニア
–
日々のしごと
●
●
●
●
ライフワーク
–
自由なソフトウェアの普及
●
●
トラブルシューティング全般
Q&A 回答
パフォーマンスチューニング
など
オープンソースではない
ブログ
–
–
漢のコンピュータ道
http://nippondanji.blogspot.com/
今日は個人として
参加しています。

4. MySQL Cluster
とは！

5. MySQL の姉妹製品
●
MySQL のストレージエンジンとして使える。
–
●
●
●
●
●
CREATE TABLE hoge (…) ENGINE NDB;
トランザクション対応
並列分散型のデータベース
HA 機能
ハイパフォーマンス
コミュニティ版は GPLv2

6. 動作イメージ
アプリケーション
アプリケーション
アプリケーション
通常の MySQL プロトコル
SQL ノード
SQL ノード
MySQL サーバー
SQL ノード
MGM API
NDB API
データ
ノード
データ
データ
ノード
ノード
データ
ノード
データ
ノード
管理ノード

7. 速いの？
●
結論： 1 台の性能では InnoDB のほうが上
–
●
ただし NDB API は爆速
ノードを並べてナンボ
–
データノード
●
●
–
SQL ノード
●
●
負荷分散
データ量の増加
SQL 解析の負荷分散
ノードを増やしても性能が伸びない処理もある
–
少ししか行を取ってこないスキャン
●
sysbench が遅い！！

8. MySQL Cluster でできること
高可用性
●
SPOF の排除
●
HA 機能搭載
●
遠隔地へのレプリケーション
パフォーマンス
●
スケールアウト
●
リアルタイム処理
●
NoSQL
低価格
●
GPL 版は無償
●
商用ライセンスもお手頃 http://www­jp.mysql.com/products/
●
コモディティなハードウェアで構築可能

9. 3 種類のノード
●
管理ノード
–
–
●
データノード
–
●
クラスターの構成情報を管理
各種操作を発行
データとトランザクションを司る
SQL ノード /API ノード
–
NDB ストレージエンジンを搭載した MySQL サーバ
●
–
NDB API を経由してデータノードへアクセス
アプリケーションが SQL ノードを介さず直接 NDB API
を叩くことも可。（ API ノード）

10. シェアードナッシング
= No SPOF
データノード 1
データノード 3
フラグメント 1
プライマリ
フラグメント 3
セカンダリ
フラグメント 2
プライマリ
フラグメント 4
セカンダリ
フラグメント 1
セカンダリ
フラグメント 3
プライマリ
フラグメント 2
セカンダリ
フラグメント 4
プライマリ
データノード 2
データノード 4
ノードグループ 1
ノードグループ 2

11. ひとつコケても大丈夫！！
データノード 1
データノード 3
dead
dead
フラグメント 2
プライマリ
フラグメント 4
セカンダリ
フラグメント 1
プライマリ
フラグメント 3
プライマリ
フラグメント 2
セカンダリ
フラグメント 4
プライマリ
データノード 2
データノード 4
ノードグループ 1
ノードグループ 2

12. ふたつコケても大丈夫！！
データノード 1
データノード 3
dead
dead
dead
dead
フラグメント 1
プライマリ
フラグメント 3
プライマリ
フラグメント 2
プライマリ
フラグメント 4
プライマリ
データノード 2
データノード 4
ノードグループ 1
ノードグループ 2

13. これはアウト！！
データノード 1
データノード 3
dead
dead
フラグメント 2
プライマリ
フラグメント 4
セカンダリ
dead
dead
フラグメント 2
セカンダリ
フラグメント 4
プライマリ
データノード 2
データノード 4
ノードグループ 1
ノードグループ 2

14. とりあえずインストール
●
●
●
●
パッケージをインストールする
config.ini と my.cnf を書く
ユーザーやデータディレクトリをつくる
プロセスを起動する
–
管理ノード→データノード→待つ→ SQL ノード

15. デモ

16. パフォーマンスの
勘所

17. 最新のバージョンを使う
●
バージョンが新しいほど高速化している！
– 6.2
● SQL ノードからデータノードへの接続を複数化
– 6.3
● スレッドのバインディング
● Distribution Awareness
● TC 選択のロジックを改善
● 主キー / ユニークキーを用いた更新の効率化
● 圧縮 LCP/ バックアップ
● epoll
– 7.0
● データノードのマルチスレッド化
● メッセージ通信の改善
● データノードのオンライン拡張

18. 最新のバージョンを使う
●
つづき
–
7.1
●
●
–
7.2
●
●
●
–
ndbinfo
BLOB へのアクセス高速化
MySQL 5.5
pushdown join
memcached の追加
性能だけでなく
バージョンが上がる
ごとに機能も増えて
どんどん便利に！
7.3
●
●
●
MySQL 5.6
– Batched Key Access Join
– Semi-Join 最適化（サブクエリ）
外部キー
NDB API のボトルネック解消

19. 非公式ベンチマーク
●
●
2011/04/11 （ 7.1 ）
– MySQL Cluster doing 6.82M reads per second
● 8 データノード
http://mikaelronstrom.blogspot.jp/2011/04/mysqlcluster-doing-682m-reads-per.html
2011/04/12 （ 7.1 ）
– MySQL Cluster running 2.46M updates per second!
● 8 データノード
http://mikaelronstrom.blogspot.jp/2011/04/mysqlcluster-running-246m-updates-per.html

20. 非公式ベンチマーク（つづき）
●
2012/05/16
–
MySQL Cluster 7.2.7 achieves 1BN update transactions
per minute
●
●
●
●
19.5M transactions/s 相当
30 データノード、各 8ldm スレッド
http://mikaelronstrom.blogspot.jp/2012/05/mysqlcluster-727-achieves-1bn-update.html
2012/05/22
–
MySQL Cluster 7.2 achieves 4.3BN reads per minute
●
●
●
72M reads/s 相当
30 データノード、各 8ldm スレッド
http://mikaelronstrom.blogspot.jp/2012/05/mysqlcluster-72-achieves-43bn-reads.html

21. 非公式ベンチマーク（つづき）
●
2012/02/15 （ 7.2 ）
– 1.05BN QPM using MySQL Cluster 7.2
● 17.5M reads/s 相当
● 8 データノード
● 主にスレッドのバインディングによる効果
● http://mikaelronstrom.blogspot.jp/2012/02/105bn-qpmusing-mysql-cluster-72.html

22. 非公式ベンチマーク（つづき）
●
2012/05/16 （ 7.2 ）
–
MySQL Cluster 7.2.7 achieves 1BN update transactions
per minute
19.5M transactions/s 相当
● 30 データノード、各 8ldm スレッド
● http://mikaelronstrom.blogspot.jp/2012/05/mysqlcluster-727-achieves-1bn-update.html
2012/05/22 （ 7.2 ）
●
●
–
MySQL Cluster 7.2 achieves 4.3BN reads per minute
●
●
●
72M reads/s 相当
30 データノード、各 8ldm スレッド
http://mikaelronstrom.blogspot.jp/2012/05/mysqlcluster-72-achieves-43bn-reads.html

23. スレッド数の調整
●
バージョン 7.0 以降
–
MaxNoOfExecutionThreads
●
●
–
7.0 〜 7.1 … 最大 8
7.2 〜 7.3 … 最大 36
TheadConfig
●
より細かな指定が可能
–
–
スレッドごとに特定の CPU にバインディング
バインディングするものとしないものの混在が可能
ThreadConfig=ldm{count=4,cpubind=1,2,3,4},
main={cpubind=5},io={cpubind=5},rep={cpubind=6},
tc{cpubind=7},recv={cpubind=8}

24. データノードの追加による
スケールアウト
●
●
主キーを使った検索（ルックアップ）はデータノード数に応じ
てスケールする
データノードは最大 48 台まで。
SQL ノード
各データノードに
負荷が均等に分散

25. 細かい範囲検索が苦手
SQL ノード
1. スキャンリクエスト
データノード
TC
すべてのデータノードが
応答を強いられる
3. データを返送
データノード
2. 他のノードへリクエスト
データノード

26. スキャンの性能特性
●
フェッチするレコード数が少ない
–
–
●
データノードが増えてもスキャン回数は頭打ち
遅い！！
フェッチするレコード数が多い
–
–
–
データノードで並列処理できるためノード数に応じて処理
時間が短くなる
Engine Condition Pushdown で並列で絞り込みが可能
速い！！

27. Engine Condition Pushdown
SQL ノード
SQL ノード
WHERE 句で
絞り込み
WHERE 句で
絞り込み
データノード
Pushdown なし
データノード
Pushdown あり

28. ユーザー定義パーティション
users
テーブル
diaries
テーブル
users
テーブル
diaries
テーブル
user_id
= 100
user_id
= 100
user_id
= 100
user_id
= 100
user_id
= 100
user_id
= 100
user_id
= 100
通常のパーティショニング
ユーザー定義パーティショニング

29. ユーザー定義パーティションの効能
●
スキャンがスケールアウト
–
–
–
●
超重要！！
特定のデータノードだけに問い合わせれば良くなるため
スケールアウトさせるにはデータノードを追加
Pushdown Join にも効果あり

30. スキャンの変化
SQL ノード
該当するパーティションの
データノードだけが
応答すれば良い
データノード
TC
データノード
データノード

31. レプリケーションによる
スケールアウト
アプリケーション
更新
マスター
SQL
ノード
データ
ノード
データ
ノード
SQL
ノード
JOIN
スレーブ
SQL
ノード
データ
ノード
データ
ノード
INNODB
スレーブ
INNODB
スレーブ
INNODB

32. MySQL Cluster の
レプリケーションアーキテクチャ
通常の
通常の
SQL
通常の
SQL
ノード
SQL
ノード
ノード
SQL による更新
SQL ノード
（バイナリログ生成）
binlog
injector
thread
バイナリログ
スレーブへ
更新内容を抽出
データノード群

33. 速いディスク
●
インメモリデータベースだけれども・・・
–
データの永続性のためにたくさんの I/O が発生する
●
●
●
更新をすべて記録する GCP （ REDO ログ）
LCP （定期的にメモリのイメージをディスクへ書き出す処
理）の速度も重要
ディスク型テーブル
–
ディスクの性能に大きく影響を受ける

34. sysbench のサンプル
3500
3000
2500
memory ro
memory rw
2000
hdd ro
hdd rw
1500
fio ro
fio rw
1000
500
0
1
4
8
12
16
32
48
64
96
128
1 server machine
1 cpu sockets
6 cores 12 threads
32GB memory
internal hdd / fusion-io
sysbench w/o range tests

35. マシンをお借りしました
マシン
ありがとう
ございます！！

36. BLOB は苦手
●
内部的に BLOB 用のテーブルが作成される
–
●
JOIN が増えるのと同じ
なるべく使わない
–
varchar で頑張る（最大サイズをきっちり決める）
●
–
最大行サイズ 14000 バイト
InnoDB と連携

37. NoSQL インターフェイス
●
SQL よりも数段速い！！
–
–
–
–
●
●
NDB API … C++ によるネイティブな API
ClusterJ … Java バインディング
memcached … ストレージエンジンとして実装
MySQL NoSQL Connector for JavaScript … Javascript バ
インディング
NDB API が最速
手軽に使うなら便利なバインディングがオススメ！

38. memcached
SQL
ノード
SQL
ノード
memcached
memcached
N D B A P I
データノード群

39. まとめ
●
MySQL Cluster はこんなときにオススメ！
–
–
–
●
更新をスケールしたい
HA 機能が欲しい
超絶高速な JOIN が欲しい
性能の特性の違いに注意！
–
–
–
得意、不得意がある
適切なスケールアウト戦略を選ぶべし！
豊富な NoSQL API

40. Q&A!!
ご静聴ありがとうございました。