AQLによるJOIN性能の大幅な向上

AQLによるJOIN性能の大幅な向上

MySQL Cluster 7.1までは、JOINするテーブルから評価対象の行を1行ずつSQLノードに取得する仕様となっていたため、JOINの処理性能がなかなか上がりませんでした。次期メジャーバージョンの7.2では、JOINは全てデータノード間に閉じて処理をし、結果だけをSQLノードに返すAdaptive Query Localization（AQL）という仕様に変更しました。

このAQLを実装した結果、10個以上のテーブルをJOINする処理で性能が70倍以上となったベンチマーク結果も出ています。
→参照：70x Faster Joins with AQL in MySQL Cluster 7.2 DMR - ANDREW MORGAN’S MYSQL CLUSTER DATABASE BLOG

MySQL Cluster 7.1まではこのJOIN性能がネックとなり、利用対象となるアプリケーションに大きな制約がありましたが、この改善によってより多くのアプリケーションでの利用が期待できます。サーバ台数を抑えた小規模なクラスタを利用して、高価な共有ディスク不要で、かつActive-Activeのクラスタを極めて安価に構築することもできます。

MySQL Cluster 7.2ではSQLノードをMySQL 5.5ベースに切り替えたことで、最新のInnoDBをMySQL Clusterと組み合わせて利用できるようになり、またMySQLサーバの性能改善ポイントも取り込みました。

ディザスタリカバリのためのソリューション

MySQL Clusterそのものでも、単一障害点が無いため高い信頼性を持っています。MySQL Cluster 7.1ではMySQLサーバのレプリケーション機能を利用して、他のクラスタにデータを転送することができます。データセンターをまたいだ非同期レプリケーションを設定することで、データセンターの被災に備えたディザスタリカバリ構成を構築してさらにシステムの信頼性を高めることができます。

また、MySQL Clusterと通常のMySQLサーバの間でもレプリケーションを設定できるため、高い性能や冗長性を求められるデータをMySQL Clusterで処理し、複数のMySQLサーバに転送して並列で分析処理などを行う構成も可能です。

MySQLサーバのレプリケーションでは、バイナリログの内容を別のMySQLサーバに転送しています。転送されるバイナリログの内容は、デフォルトではコミットされたトランザクションのSQL文を記録する文ベースですが、変更後のデータを記録する行ベースも選択可能です。MySQL Clusterの場合は行ベースでのレプリケーションのみになります。

MySQL Clusterでは複数のMySQLサーバがSQLノードとして利用されますが、バイナリログ・インジェクションという仕組みによって、データノードでのデータ変更が終了した時点で、他のSQLノードから実行されたSQL文もデータノードからSQLノードのバイナリログにシリアライズされた上で書き込まれます。

MySQL Cluster独自のレプリケーション機能の拡張としては、双方向のレプリケーションを利用した場合のテーブル単位での矛盾点の検知と解消が挙げられます。双方向のレプリケーションでは、非同期で変更内容を転送するため、データ変更処理の順序がそれぞれのサーバで入れ替わってしまう可能性があります。MySQL Cluster 7.1では、テーブルにタイムスタンプに類似する整数型の列を用意し、アプリケーション側で一意にシーケンス番号を生成してテーブル変更時にこの値を格納することで、レプリケーション時に矛盾の有無を検知し、矛盾があればシーケンス番号が大きい方を優先する、または削除処理を優先することで矛盾を解消します。

MySQL Cluster 7.2では、更新処理をまとめたEpochを、IDとメタデータを管理するテーブルに格納してレプリケーション処理時にチェックされるようになるため、アプリケーションのデータを格納するテーブルに矛盾検知用のタイムスタンプ格納列を追加する必要が無くなり、より利用しやすくなります。

非同期でのレプリケーションよりもさらに高いレベルでの信頼性を確保するため、MySQL Cluster 7.2ではデータノードを複数のデータセンターに分散させて配置することで、データセンターをまたいで同期的にデータを書き込むことができるようになり、極めて高い信頼性を持った環境が構築できます。既に海外の通信機器ベンダが先行ユーザとしてオーストラリアのシドニーとメルボルンのデータセンターをつないで運用しています。