カジュアルにMySQL Clusterを使ってみよう@MySQL Cluster Casual Talks 2013.09
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 5,591 views

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

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

Statistics

Views

Total Views
5,591
Views on SlideShare
2,303
Embed Views
3,288

Actions

Likes
18
Downloads
73
Comments
0

16 Embeds 3,288

http://b.l0g.jp 1615
http://nippondanji.blogspot.jp 1563
http://www.l0g.jp 68
http://nippondanji.blogspot.com 19
http://webcache.googleusercontent.com 6
http://s.deeeki.com 3
http://nippondanji.blogspot.fr 2
http://nippondanji.blogspot.ca 2
http://nippondanji.blogspot.kr 2
http://news.google.com 2
http://www.google.co.jp 1
http://newsblur.com 1
https://twitter.com 1
http://nippondanji.blogspot.sg 1
http://nippondanji.blogspot.tw 1
http://slideshare-download.seesaa.net 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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