sgykfjsm.github.com

MySQL Cluster Casual Talksに行ってきた

MySQL Casual Talkと勘違いしてたけど、とても勉強になった。 以下はメモ。

MySQL Cluster大地に立つ! 「5.6とは違うのだよ、5.6とは!」

@RKajiyamaさん

MySQLクラスタとは

  • MySQL Cluster
    • 独立した製品
    • MySQLのクラスタリングのことではない
    • v7.3
      • MySQL Serverとは違う。共通点はあるけど。
    • MySQL Serverとの最大の違いは分散型DBであること。
      • 共有ディスクはいらない
      • メモリが豊富で性能の優れたディスクを持つサーバ
    • 全ノードがアクティブ
    • シェアードナッシング
      • 共有ディスクは不要
    • 全オード多重化
    • ノードを増やすことで負荷分散と多重化を図ることが可能
      • 多重化はRAID0と同じ
    • アプリケーションレイヤから見るとACID KVSとして利用可能
      • MySQL Serverを経由せずにアプリケーションから直接Clusterにアクセスできる。
      • ACIDを維持しても20M updates sec
    • 主要な利用企業はzynga, NEC, at&t, paypal, ericsson, cisco, vodafon, US Navyなど
      • PayPalは基盤をすべてMySQLで構築しているらしい
    • NoSQLとしてのMySQL
      • アプリケーションからはNoSQLのように見えるが、内部的にはコンテナテーブルによりデータがテーブルや絡むとマッピングされて、内部的にはRDBとして動作する。
    • Apps -> JPA -> Cluster JPA -> Cluster J -> JNI -> NDB API -> データレイヤがJavaのアクセス経路
      • ただしJOINなどの場合は自動的にJDBCに振り分けがされる。

MySQL Clusterをカジュアルに使ってみよう!

@nippondanjiさん

MySQL Clusterとは!

  • MySQLのストレージエンジンとして使える
    • create table hoge (…) engnie ndb;
  • トランザクション対応
  • 並列分散型のDB
  • HA機能
  • ハイパフォーマンス
  • コミュニティ版はGPLv2
  • アプリケーションとデータノードの間にSQLノードをぶら下げる
    • 255ノードまでぶら下げることが可能
    • データノードは最大48ノード
  • 速いか?
    • 1台の性能ではInnoDBのほうが↑
      • NDB APIは爆速
    • ノードを並べてナンボ
      • データノード
        • 負荷分散
        • データ量の増加
      • SQLノード
        • SQL解析の負荷分散
    • ちょっとしか参照しない処理ではノードを増やしても性能は上がらない
  • 高可用性
    • SPOFの排除
    • HA機能搭載
    • 遠隔地へのレプリケーション
  • コモディティなハードウェアでも搭載可能
  • ノードは3種類
    • 管理ノード
    • データノード
    • SQLノード/APIノード
  • シェアードナッシング
    • 同じノードグループ内でミラーリングし合う
    • ミラーの相手側が落ちたとしても相手のプライマリや自分の中にレプリケーションデータを作成する
  • インストールのデモ
    • 確かにカジュアルに使えそうにみえるが…
  • パフォーマンス・チューニング
    • 最新バージョンを使う!
    • バージョンが上がるほど高速化している
    • v6.2 → SQLノードからデータノードへの接続を複数可
    • V6.3 → スレッドのバインディング、TC選択のロジックを改善
    • v7.0 → データノードがマルチスレッド化、メッセージ通信の改善、データノードのオンライン拡張
    • v7.1 → ndbinfo, BLOBへのアクセス高速化
    • v7.2 → MySQL5.5、pushdown join、memcachedの追加
    • v7.3 → MysQL5.6 外部キー、NDB APIのボトルネック解消、Semi Joinの最適化
  • データノード数は最大48台
    • 主キーを使った検索は速い、スケールする
    • 範囲検索(スキャン)は苦手、スケールしない(しづらい)
      • フェッチするレコード数が少ないと遅い
      • フェッチするレコード数が多いとデータノードで並列処理がされるので、思ったより速い
    • ユーザ定義パーティションによりスキャンを克服する
      • 外部キーを設定するイメージ
      • スキャンがスケール
      • 特定のデータノードに問い合わせれば良くなるためJOINもスケールする
    • レプリケーションによるスケールアウト
      • レプリケーション先をInnoDBとすることでスキャンもスケールさせることができる
  • MySQL Clusterはインメモリデータベースだけれども
    • データの永続性のために沢山のI/Oが発生する
      • REDOログ
      • LCP(local check point)
  • ディスク型テーブル
    • ディスクの性能に大きく影響する
    • ベンチマーク上はHDDを利用するとスケールしなくなる
    • インメモリ型だとCPUが貧弱でもスケールする
  • BLOBは苦手
    • 内部的にBLOB用のテーブルが作成される
      • JOINが増えるのと同じ
      • varcharで頑張ってみる。でもなるべく使わないほうが良い
  • NoSQLインターフェース
    • SQLよりも数段速い
      • NDB API
      • Cluster J
      • memcached
      • java用のバインディング
  • MySQL Clusterは以下の場合に向いている
    • 更新をスケールしたい
    • HA機能が欲しい
    • 超絶高速なJOINが欲しい
    • 得意、不得意を踏まえて適切なスケールアウト戦略を選ぶべし
    • NoSQL APIが豊富
  • 管理ノードはSPOF?
    • 管理ノードは2つ用意することが出来ない
    • 管理ノードは落ちても動作には影響しない
    • SQLノードが管理ノードの代わりを果たす?←ちゃんと聞き取れなかった…

MySQL Clusterと丸4年の付き合いを振り返ってのよもやま話と、Version 7.3への期待(もっとユーザが増えるといいな~)

@tsakuradaさん

なぜMySQL Clusterを使うか?

  • インメモリ型であること
    • 確かに速いがioDrive + InnoDBの組み合わせでかなり高い性能がでるので、優位性は揺らぎつつ有るかも?
  • コモディティなサーバでもOK
    • 結局メモリが必要なので安価でOKとは限らない
    • スケールアウトが難しいケースはやはりある
  • 高可用性
    • 今でも優位性を保っているが、ポイントを押さえておかないと無意味になる。

改めて主張したい優位点

  • GPLv2
  • MySQL(InnoDB)との互換性がv7.3以降でかなり向上した

導入 - どう使うか

  • SQLノード、MGMノード、データノードの構成が設計のキモ
  • それぞれを単体にしても動くけど、SPOFを排除するためには各ノードを複数配置するのが普通
  • データ量が増えた
    • データノードのメモリを増やすか、データノードの数を増やす
    • スケールアウトを考えてデータノードを増やすようにしたほうが良い
  • アクセス増えた
    • SQLノードを増やす
  • 高可用性を活かすためには
    • ハードウェア構成上SPOFが無い様に2重化する
    • 多重化障害にどこまで対応するかは悩ましい
    • 実行中のクエリをキャンセルされた時には、エラーをキャッチして後続処理を適切に作りこむ必要がある
      • 条件に応じた適切な処理をアプリケーションに実装するのがキモ
  • InnoDBと同じ感覚でテーブル設計していいのか?
    • やってみるのが一番
    • いろんなかたちでベンチマークを取ってみる
  • バッチ処理のことも考えてInnoDBと組み合わせたい
    • 高潰瘍性のレベルがInnoDB側に引っ張られることになる
    • NDBとInnoDBはトランザクションの分離レベルが違うので、その点でも注意する必要がある。

運用 - 何が起きるか

ハマりどころ

  • GCP Stop!
    • Global check point
    • これが無いと永続性が保たれなくなる
    • これが何らかの理由で停止されるとデータノードがシャットダウンされてしまう
    • 一度のコミットにかかる時間が一定のしきい値を超過した場合にGCP Stopが発生してしまう。
    • アプリ側でコミットにかかる時間を把握してクエリを発行する必要がある
    • 最新バージョンではこの閾値を無制限に指定できるので、それで逃げる必要がある。ただ、本当に以上が発生した場合にはDBが固まってしまうので、リスクとのトレードオフ。
  • ローリングリスタート
    • NDBのパラメータ変更を反映するためにデータノードの再起動が必要になる場合がある。
    • 再起動中にミラーリング相手が落ちてしまうと障害が発生してしまう。
    • データノードが保有するデータ量が多いと再起動に時間がかかるため、多重障害の発生確率が高まってしまう。
    • オンラインでのローリングリスタートはやはり怖い
    • リスタート中はDDL文が発行できないなどの仕様上の制約がある。
    • 最新のバージョンでは起動も拘束しているが、メモリ上にデータを展開してインデックスの構築に時間がかかる。
  • ボトルネックが見えづらい
    • vmstatやiostatでは見えないところでボトルネックが発生していることがある。
    • Slowログに主キーでのselectが出てくることがある。
    • 見えづらいというよりかは、確認ポイントが多い
      • データノードは?
      • SQLノードは?
      • NWは?
      • ndbinfoは?
  • データのライフサイクルをどうするか?
    • メモリの節約のためにDELETE文を発行する必要があるが、DELETE文はやはりオソい
    • DELETE文で空いた領域はデータノードを再起動しない限りは同じテーブル内でしか再利用できない。DROP TABLEしちゃえば良いらしい。
  • バックアップは良いけどリストアが…
    • NDBには専用のオンライン・バックアップ機能がある
    • 100GBぐらいをリストアすると半日以上かかる

まとめ

  • 高可用性システムを構築する上でMysQL Clusterはいい選択
  • ただ色々考慮するポイントがある

MySQL Cluster Auto Installerのデモ

  • GUIでセットアップする Auto Installerがv7.3が付属するようになった
  • マルチホストサポート

うっかり間違えて参加したけど、とても勉強になるいい回だった。発表者はプレゼンなれしてるなーって感じでわかりやすかったし。
MySQL Clusterは話を聞いてると確かにCasualに使えそうだけど、改めてCasualをアピールしてるってことは実際には結構運用が大変なんだろーなーということは想像がつく。けど、面白そうだしこうゆう製品を扱う経験はエンジニアなら一度はしたいところ。