Post on 25-Jun-2015
description
MySQL ClusterMySQL Cluster をを使ってみよう！使ってみよう！
奥野幹也@nippondanjimikiya (dot) okuno (at) gmail (dot) com
@MySQL Cluster Casual Talks 2013
カジュアルに
免責事項● 本プレゼンテーションにおいて示されている見解は、私自身の見解であって、オラクル・コーポレーションの見解を必ずしも反映したものではありません。ご了承ください。
自己紹介
● MySQLサポートエンジニア– 日々のしごと
● トラブルシューティング全般● Q&A回答● パフォーマンスチューニング
など● ライフワーク
– 自由なソフトウェアの普及● オープンソースではない
● ブログ– 漢のコンピュータ道– http://nippondanji.blogspot.com/
今日は個人として参加しています。
MySQL Clusterとは！
MySQLの姉妹製品
● MySQLのストレージエンジンとして使える。– CREATE TABLE hoge (…) ENGINE NDB;
● トランザクション対応● 並列分散型のデータベース● HA機能● ハイパフォーマンス● コミュニティ版は GPLv2
動作イメージ
データノード
SQL ノード
アプリケーション アプリケーション アプリケーション
NDB API
通常のMySQLプロトコル
管理ノード
SQL ノード SQL ノード
データノードデータノード
データノード
データノード
MGM API
MySQLサーバー
速いの？
● 結論： 1台の性能では InnoDBのほうが上– ただし NDB APIは爆速
● ノードを並べてナンボ– データノード
● 負荷分散● データ量の増加
– SQL ノード● SQL解析の負荷分散
● ノードを増やしても性能が伸びない処理もある– 少ししか行を取ってこないスキャン
● sysbenchが遅い！！
MySQL Clusterでできること
高可用性●SPOF の排除●HA 機能搭載●遠隔地へのレプリケーション
パフォーマンス●スケールアウト●リアルタイム処理●NoSQL
低価格●GPL 版は無償●商用ライセンスもお手頃 http://wwwjp.mysql.com/products/●コモディティなハードウェアで構築可能
3種類のノード
● 管理ノード– クラスターの構成情報を管理– 各種操作を発行
● データノード– データとトランザクションを司る
● SQL ノード /API ノード– NDB ストレージエンジンを搭載した MySQL サーバ
● NDB API を経由してデータノードへアクセス– アプリケーションが SQL ノードを介さず直接 NDB API
を叩くことも可。（ API ノード）
シェアードナッシング= No SPOF
ノードグループ 1
データノード 1
データノード 2
フラグメント 1プライマリ
フラグメント 3セカンダリ
フラグメント 1セカンダリ
フラグメント 3プライマリ
ノードグループ 2
データノード 3
データノード 4
フラグメント 2プライマリ
フラグメント 4セカンダリ
フラグメント 2セカンダリ
フラグメント 4プライマリ
ひとつコケても大丈夫！！
ノードグループ 1
データノード 1
データノード 2
dead dead
フラグメント 1プライマリ
フラグメント 3プライマリ
ノードグループ 2
データノード 3
データノード 4
フラグメント 2プライマリ
フラグメント 4セカンダリ
フラグメント 2セカンダリ
フラグメント 4プライマリ
ふたつコケても大丈夫！！
ノードグループ 1
データノード 1
データノード 2
dead dead
フラグメント 1プライマリ
フラグメント 3プライマリ
ノードグループ 2
データノード 3
データノード 4
dead dead
フラグメント 2プライマリ
フラグメント 4プライマリ
これはアウト！！
ノードグループ 1
データノード 1
データノード 2
dead dead
dead dead
ノードグループ 2
データノード 3
データノード 4
フラグメント 2プライマリ
フラグメント 4セカンダリ
フラグメント 2セカンダリ
フラグメント 4プライマリ
とりあえずインストール
● パッケージをインストールする● config.iniとmy.cnfを書く● ユーザーやデータディレクトリをつくる● プロセスを起動する
– → → →管理ノード データノード 待つ SQL ノード
デモ
パフォーマンスの勘所
最新のバージョンを使う
● バージョンが新しいほど高速化している！– 6.2
● SQL ノードからデータノードへの接続を複数化– 6.3
● スレッドのバインディング● Distribution Awareness● TC選択のロジックを改善● 主キー /ユニークキーを用いた更新の効率化● 圧縮 LCP/バックアップ● epoll
– 7.0● データノードのマルチスレッド化● メッセージ通信の改善● データノードのオンライン拡張
最新のバージョンを使う
● つづき– 7.1
● ndbinfo● BLOBへのアクセス高速化
– 7.2● MySQL 5.5● pushdown join● memcachedの追加
– 7.3● MySQL 5.6
– Batched Key Access Join– Semi-Join最適化（サブクエリ）
● 外部キー● NDB APIのボトルネック解消
性能だけでなくバージョンが上がるごとに機能も増えてどんどん便利に！
非公式ベンチマーク
● 2011/04/11 （ 7.1 ）– MySQL Cluster doing 6.82M reads per second
● 8データノードhttp://mikaelronstrom.blogspot.jp/2011/04/mysql-cluster-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/mysql-cluster-running-246m-updates-per.html
非公式ベンチマーク（つづき）
● 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/mysql-
cluster-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/mysql-
cluster-72-achieves-43bn-reads.html
非公式ベンチマーク（つづき）
● 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-qpm-
using-mysql-cluster-72.html
非公式ベンチマーク（つづき）
● 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/mysql-
cluster-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/mysql-
cluster-72-achieves-43bn-reads.html
スレッド数の調整
● バージョン 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}
データノードの追加によるスケールアウト
● 主キーを使った検索（ルックアップ）はデータノード数に応じてスケールする
● データノードは最大 48台まで。
SQLノード各データノードに
負荷が均等に分散
細かい範囲検索が苦手
データノードTC
データノード データノード
SQLノード
1.スキャンリクエスト
2.他のノードへリクエスト
3.データを返送
すべてのデータノードが応答を強いられる
スキャンの性能特性
● フェッチするレコード数が少ない– データノードが増えてもスキャン回数は頭打ち– 遅い！！
● フェッチするレコード数が多い– データノードで並列処理できるためノード数に応じて処理時間が短くなる
– Engine Condition Pushdownで並列で絞り込みが可能– 速い！！
Engine Condition Pushdown
データノード
SQLノード
データノード
SQLノード
Pushdownなし Pushdownあり
WHERE 句で絞り込み
WHERE 句で絞り込み
ユーザー定義パーティション
通常のパーティショニング ユーザー定義パーティショニング
usersテーブル
user_id= 100
user_id= 100
user_id= 100
user_id= 100
user_id= 100
user_id= 100
user_id= 100
diariesテーブル
usersテーブル
diariesテーブル
ユーザー定義パーティションの効能
● スキャンがスケールアウト– 超重要！！– 特定のデータノードだけに問い合わせれば良くなるため– スケールアウトさせるにはデータノードを追加
● Pushdown Joinにも効果あり
スキャンの変化
データノードTC
データノード データノード
SQLノード
該当するパーティションのデータノードだけが
応答すれば良い
レプリケーションによるスケールアウト
データノード
データノード
データノード
データノード
SQLノード
スレーブマスター
INNODBINNODB
スレーブ
INNODBINNODB
スレーブ
INNODBINNODB
更新
SQLノード
SQLノード
JOINアプリケーション
MySQL Clusterのレプリケーションアーキテクチャ
データノード群
SQL ノード（バイナリログ生成）通常の
SQLノード
通常のSQLノード
通常のSQLノード
SQLによる更新
binloginjectorthread
更新内容を抽出
バイナリログ
スレーブへ
速いディスク
● インメモリデータベースだけれども・・・– データの永続性のためにたくさんの I/Oが発生する
● 更新をすべて記録する GCP （ REDOログ）● LCP （定期的にメモリのイメージをディスクへ書き出す処理）の速度も重要
● ディスク型テーブル– ディスクの性能に大きく影響を受ける
sysbenchのサンプル
1 4 8 12 16 32 48 64 96 1280
500
1000
1500
2000
2500
3000
3500
memory ro
memory rw
hdd ro
hdd rw
fio ro
fio rw
1 server machine1 cpu sockets6 cores 12 threads32GB memoryinternal hdd / fusion-iosysbench w/o range tests
マシンをお借りしました
マシンありがとうございます！！
BLOBは苦手
● 内部的に BLOB用のテーブルが作成される– JOINが増えるのと同じ
● なるべく使わない– varcharで頑張る（最大サイズをきっちり決める）
● 最大行サイズ 14000バイト– InnoDBと連携
NoSQLインターフェイス
● SQLよりも数段速い！！– NDB API … C++によるネイティブな API– ClusterJ … Javaバインディング– memcached … ストレージエンジンとして実装– MySQL NoSQL Connector for JavaScript … Javascriptバインディング
● NDB APIが最速● 手軽に使うなら便利なバインディングがオススメ！
memcached
SQLノード
SQLノード
memcached memcached
N D B A P I
データノード群
まとめ
● MySQL Clusterはこんなときにオススメ！– 更新をスケールしたい– HA機能が欲しい– 超絶高速な JOINが欲しい
● 性能の特性の違いに注意！– 得意、不得意がある– 適切なスケールアウト戦略を選ぶべし！– 豊富な NoSQL API
Q&A!!ご静聴ありがとうございました。