MySQL Master HA and Write Scale-out

MySQLとNoSQL

  • MySQLでは、マスタ：スレーブを１：N構成とすることで、参照系クエリを複数のスレーブに振り分けることができ、スレーブを増やすことによって参照系クエリのスケールアウトが可能。
  • 更新系クエリは、データを一意に保つためマスタ1台で対応することになるが、スレーブと同期する手前、マスタだけを極端にスケールアップすることは避けた方が良い。スレーブ側のリレーログの適用が追いつかなくなる。
  • MySQL 5.1からはパーティショニング機能によって、RANGEやHASHなどによってパーティショニングされた表を、別々の物理ドライブにストライプできるため、複数のパーティションが同時にアクセスされる場合の物理I/Oの競合を抑えることが可能。*1
  • 一方、CassandraなどのNoSQLでは、データベースの持つシャーディング機能によって、書き込み領域を持つノードを物理的に分散させることができるので、ノードを増やすことによって更新系のクエリのスケールアウトが可能。
  • ただし、シャーディング機能によって分割されたテーブルにおける結合や集約、任意のソートなどを絡めた複雑なRDB系のクエリは、NoSQLでは基本的にサポートされていない。
  • また、NoSQLではトランザクションというACID特性を満たす操作がサポートされていない。
  • さらに、InnoDBログファイルやDoubleWriteのような、耐障害性を保証する機能もない。だから、永続的なデータを保存する用途には向かないが、セッション情報のような短命なデータを保存する用途に向いている。
  • 単純にキーと値がバインドされているようなスキーマ（Key-Value Store）を扱う場合は、手軽に扱えるためNoSQLは使い勝手が良い。テーブルのスキーマを変更するコストも低い。
  • MySQL単体で更新系クエリのためにシャーディングを実現するためには、クライアントからSQLを発行する前に、アプリケーションロジック上で対応する必要がある。その場合も、NoSQLと同じようにRDB操作には高いコストが伴う。

MySQL Cluster ( NDBCluster )

  • HadoopのHDFSを思わせる、RAID10的なノード構成で、高い可用性を実現する。モバイル網のバックエンドなどに使われている。
  • MySQL Serverとは開発ツリーは別で、ストレージエンジンとしてNDB Engineを開発。
  • データノードを増やすことでシャーディングを実現し、SQLノードを増やすことでクライアントからの接続を分散する。データが複数ノードに分散されており、各ノードのメモリを利用したインメモリデータベースを実現しており高速である。
  • 管理ノードをHA化して障害時に高速な自動フェールオーバーが可能。
  • フェッチするレコード数が多いほど、データノードの数の応じてスケールする。
  • ver7.3でMySQL 5.6がマージされた。NDB EngineとInnoDB Engineの棲み分けが可能。
  • Condition Push Downやユーザ定義パーティションなど、MySQL Clusterの構成独自の性能向上機能がある。
  • 高速なJOIN（結合）処理が必要になったときは、レプリケーション先でInnoDBを使いましょう。バイナリログは、SQLサーバのbinlog injector threadが生成している。

SPIDER engine

HandlerSocket

MySQL Fabric

*1:MySQL 5.1ではパーティショニングに指定するカラムの型はIntegerだけであったが、MySQL 5.5からは文字列の指定も可能になった

*2:ただし、どの程度複雑なクエリがベンチマークに使われていたのかは不明。

*3:Semi-SyncのサポートやInnoDBと同等の耐障害性があるかどうかは不明。