カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09

15,239 views
15,748 views

Published on

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

Published in: Technology
0 Comments
24 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,239
On SlideShare
0
From Embeds
0
Number of Embeds
9,450
Actions
Shares
0
Downloads
99
Comments
0
Likes
24
Embeds 0
No embeds

No notes for slide

カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09

  1. 1. カジュアルに MySQL Cluster を 使ってみよう! @MySQL Cluster Casual Talks 2013 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com
  2. 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご 了承ください。
  3. 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● ● ● ● ライフワーク – 自由なソフトウェアの普及 ● ● トラブルシューティング全般 Q&A 回答 パフォーマンスチューニング など オープンソースではない ブログ – – 漢のコンピュータ道 http://nippondanji.blogspot.com/ 今日は個人として 参加しています。
  4. 4. MySQL Cluster とは!
  5. 5. MySQL の姉妹製品 ● MySQL のストレージエンジンとして使える。 – ● ● ● ● ● CREATE TABLE hoge (…) ENGINE NDB; トランザクション対応 並列分散型のデータベース HA 機能 ハイパフォーマンス コミュニティ版は GPLv2
  6. 6. 動作イメージ アプリケーション アプリケーション アプリケーション 通常の MySQL プロトコル SQL ノード SQL ノード MySQL サーバー SQL ノード MGM API NDB API データ ノード データ データ ノード ノード データ ノード データ ノード 管理ノード
  7. 7. 速いの? ● 結論: 1 台の性能では InnoDB のほうが上 – ● ただし NDB API は爆速 ノードを並べてナンボ – データノード ● ● – SQL ノード ● ● 負荷分散 データ量の増加 SQL 解析の負荷分散 ノードを増やしても性能が伸びない処理もある – 少ししか行を取ってこないスキャン ● sysbench が遅い!!
  8. 8. MySQL Cluster でできること 高可用性 ● SPOF の排除 ● HA 機能搭載 ● 遠隔地へのレプリケーション パフォーマンス ● スケールアウト ● リアルタイム処理 ● NoSQL 低価格 ● GPL 版は無償 ● 商用ライセンスもお手頃 http://www­jp.mysql.com/products/ ● コモディティなハードウェアで構築可能
  9. 9. 3 種類のノード ● 管理ノード – – ● データノード – ● クラスターの構成情報を管理 各種操作を発行 データとトランザクションを司る SQL ノード /API ノード – NDB ストレージエンジンを搭載した MySQL サーバ ● – NDB API を経由してデータノードへアクセス アプリケーションが SQL ノードを介さず直接 NDB API を叩くことも可。( API ノード)
  10. 10. シェアードナッシング = No SPOF データノード 1 データノード 3 フラグメント 1 プライマリ フラグメント 3 セカンダリ フラグメント 2 プライマリ フラグメント 4 セカンダリ フラグメント 1 セカンダリ フラグメント 3 プライマリ フラグメント 2 セカンダリ フラグメント 4 プライマリ データノード 2 データノード 4 ノードグループ 1 ノードグループ 2
  11. 11. ひとつコケても大丈夫!! データノード 1 データノード 3 dead dead フラグメント 2 プライマリ フラグメント 4 セカンダリ フラグメント 1 プライマリ フラグメント 3 プライマリ フラグメント 2 セカンダリ フラグメント 4 プライマリ データノード 2 データノード 4 ノードグループ 1 ノードグループ 2
  12. 12. ふたつコケても大丈夫!! データノード 1 データノード 3 dead dead dead dead フラグメント 1 プライマリ フラグメント 3 プライマリ フラグメント 2 プライマリ フラグメント 4 プライマリ データノード 2 データノード 4 ノードグループ 1 ノードグループ 2
  13. 13. これはアウト!! データノード 1 データノード 3 dead dead フラグメント 2 プライマリ フラグメント 4 セカンダリ dead dead フラグメント 2 セカンダリ フラグメント 4 プライマリ データノード 2 データノード 4 ノードグループ 1 ノードグループ 2
  14. 14. とりあえずインストール ● ● ● ● パッケージをインストールする config.ini と my.cnf を書く ユーザーやデータディレクトリをつくる プロセスを起動する – 管理ノード→データノード→待つ→ SQL ノード
  15. 15. デモ
  16. 16. パフォーマンスの 勘所
  17. 17. 最新のバージョンを使う ● バージョンが新しいほど高速化している! – 6.2 ● SQL ノードからデータノードへの接続を複数化 – 6.3 ● スレッドのバインディング ● Distribution Awareness ● TC 選択のロジックを改善 ● 主キー / ユニークキーを用いた更新の効率化 ● 圧縮 LCP/ バックアップ ● epoll – 7.0 ● データノードのマルチスレッド化 ● メッセージ通信の改善 ● データノードのオンライン拡張
  18. 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. 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. 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. 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. 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. 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. 24. データノードの追加による スケールアウト ● ● 主キーを使った検索(ルックアップ)はデータノード数に応じ てスケールする データノードは最大 48 台まで。 SQL ノード 各データノードに 負荷が均等に分散
  25. 25. 細かい範囲検索が苦手 SQL ノード 1. スキャンリクエスト データノード TC すべてのデータノードが 応答を強いられる 3. データを返送 データノード 2. 他のノードへリクエスト データノード
  26. 26. スキャンの性能特性 ● フェッチするレコード数が少ない – – ● データノードが増えてもスキャン回数は頭打ち 遅い!! フェッチするレコード数が多い – – – データノードで並列処理できるためノード数に応じて処理 時間が短くなる Engine Condition Pushdown で並列で絞り込みが可能 速い!!
  27. 27. Engine Condition Pushdown SQL ノード SQL ノード WHERE 句で 絞り込み WHERE 句で 絞り込み データノード Pushdown なし データノード Pushdown あり
  28. 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. 29. ユーザー定義パーティションの効能 ● スキャンがスケールアウト – – – ● 超重要!! 特定のデータノードだけに問い合わせれば良くなるため スケールアウトさせるにはデータノードを追加 Pushdown Join にも効果あり
  30. 30. スキャンの変化 SQL ノード 該当するパーティションの データノードだけが 応答すれば良い データノード TC データノード データノード
  31. 31. レプリケーションによる スケールアウト アプリケーション 更新 マスター SQL ノード データ ノード データ ノード SQL ノード JOIN スレーブ SQL ノード データ ノード データ ノード INNODB スレーブ INNODB スレーブ INNODB
  32. 32. MySQL Cluster の レプリケーションアーキテクチャ 通常の 通常の SQL 通常の SQL ノード SQL ノード ノード SQL による更新 SQL ノード (バイナリログ生成) binlog injector thread バイナリログ スレーブへ 更新内容を抽出 データノード群
  33. 33. 速いディスク ● インメモリデータベースだけれども・・・ – データの永続性のためにたくさんの I/O が発生する ● ● ● 更新をすべて記録する GCP ( REDO ログ) LCP (定期的にメモリのイメージをディスクへ書き出す処 理)の速度も重要 ディスク型テーブル – ディスクの性能に大きく影響を受ける
  34. 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. 35. マシンをお借りしました マシン ありがとう ございます!!
  36. 36. BLOB は苦手 ● 内部的に BLOB 用のテーブルが作成される – ● JOIN が増えるのと同じ なるべく使わない – varchar で頑張る(最大サイズをきっちり決める) ● – 最大行サイズ 14000 バイト InnoDB と連携
  37. 37. NoSQL インターフェイス ● SQL よりも数段速い!! – – – – ● ● NDB API … C++ によるネイティブな API ClusterJ … Java バインディング memcached … ストレージエンジンとして実装 MySQL NoSQL Connector for JavaScript … Javascript バ インディング NDB API が最速 手軽に使うなら便利なバインディングがオススメ!
  38. 38. memcached SQL ノード SQL ノード memcached memcached N      D      B               A      P      I データノード群
  39. 39. まとめ ● MySQL Cluster はこんなときにオススメ! – – – ● 更新をスケールしたい HA 機能が欲しい 超絶高速な JOIN が欲しい 性能の特性の違いに注意! – – – 得意、不得意がある 適切なスケールアウト戦略を選ぶべし! 豊富な NoSQL API
  40. 40. Q&A!! ご静聴ありがとうございました。

×