Skip navigation links
14.13 MySQL Cluster の既知の制限 »
Section Navigation      [Toggle]

14.12.2. Cluster インターコネクトの理解する

ndbd プロセスには多くの簡単な構成があり、MySQL Cluster のアクセスに使用します。それらのパフォーマンスおよび様々なインターコネクトがそのパフォーマンスに及ぼす影響をチェックする簡単なベンチマークを作成しました。

4 つのアクセス方法があります。

  • プライマリ キーアクセス

    これはレコードのそのプライマリ キーによるアクセスです。最も簡単なケースでは、一度に 1 つのレコードのみによるアクセスさせます。それによって 多くのTCP/IP のメッセージの設定の全コストおよびスイッチングのコンテキストの多くのコストはこの 1 つのリクエストから生じます。この場合複数のプライマリ キーのアクセスは 1 回のバッチで送られ、それらのアクセスは TCP/IP メッセージの必要な設定およびスイッチのコンテキストに要する費用を分担します。TCP/IP メッセージのディスティネーションが異なる場合、新たに TCP/IP メッセージを設定する必要があります。

  • 一意のキーアクセス

    一意のキーアクセスは一意のキーアクセスはテーブルのプライマリ キーアクセスに続くインデックス テーブルの読み込みとして実行され以外はプライマリ キーアクセスに類似しています。しかし、MySQL サーバーからはリクエストが 1 つだけ送られ、インデックス テーブルの読み込みは ndbd によって処理されます。それらのリクエストはバッチにより恩恵を受けます。

  • テーブルの完全スキャン

    テーブルのルックアップにインデックスが存在しない場合、テーブルの完全スキャンを実施します。これは 1 つのリクエストとして ndbd プロセスに送られ、そこでテーブルスキャンをすべてのクラスタ ndbd プロセスの一連の並列スキャンに分割します。将来的には MySQL Cluster のバージョン、SQL ノードはこれらのスキャンのいくつかをフィルタできるようになります。

  • 順序付けされたインデックスを仕様したレンジ スキャン

    順序付けされたインデックスを使用すると、SQL サーバー（SQL ノード）　により転送されたクエリの範囲にあるそれらのレコードのみをスキャンする以外は、全なテーブルのスキャンと同様にスキャンを実施します。すべての結合した属性がパーティッション キーのすべての属性を含む場合パーティッションは並列でスキャンされます。

これらのアクセス方法の基本的なパフォーマンスをチェックするために、一連のベンチマークを開発しました。そのようなベンチマークの一つは、testReadPerf、でｎ簡単なバッチのプライマリおよび一意のキーアクセスをテストします。このベンチマークはまた 1 つのレコードを返すスキャンを発行することで範囲スキャンの設定コストを測定します。範囲スキャンを使用してレコードのバッチを取り出すこのベンチマークの派生版もあります。

この様に、基本となるアクセス方法で、使用している通信メディアの影響を測定するばかりでなく、1 つのキーアクセスおよび 1 つのレコードスキャン アクセスの両方のコストを決定できます。

弊社のテストでは、これらのベンチマークを TCP/IP ソケットを使用した通常のトランスポーターおよび SCI ソケットを使用した類似の設定の両方に使用しています。以下テーブルのレポートした図はアクセス毎に 20 レコードの小さなアクセスに使用します。シリアルおよびバッチのアクセスは 2KB のレコードを使用した場合 3 と 4 の因数が減少します。SCI ソケットは 2KB レコードでテストしていません。テストは AMD 社の MP1900+ プロセッサを搭載した 2 つのデュアル CPU マシン上で動作する 1 つのクラスタに 2 つのデータ ノードで実行しました。

アクセス タイプ TCP/IP ソケット SCI ソケット
シリアル pk アクセス 400 マイクロセカンド 160 マイクロセカンド
バッチ pk アクセス 28 マイクロセカンド 22 マイクロセカンド
シルアル uk アクセス 500 マイクロセカンド 250 マイクロセカンド
バッチuk アクセス 70 マイクロセカンド 36 マイクロセカンド
インデックス eq-バウンド 1250 マイクロセカンド 750 マイクロセカンド
インデックス レンジ 24 マイクロセカンド 12 マイクロセカンド

SCI ソケット vis-à-vis と SCI トランスポーターのパフォーマンス、およびこれら両方を TCP/IP トランスポーターと比較したパフォーマンスをチェックしました。これらすべてのテストにはプライマリ キーアクセスをシリアルおよび複数のスレッド、あるいは複数のスレッドおよびバッチのいずれかに使用しました。

このテストでは SCI ソケットが TCP/IP よりもおよそ 100% 早いことが分かりました。SCI トランスポーターは SCI ソケットに比べると殆どのケースで速くなっています。テスト プログラムの多くのスレッドで注目すべきことが発生した。それは SCI トランスポーターは mysqld プロセスに使用した場合あまりよい結果を示しませんでした。

全体的な結論としては、通信のパフォーマンスが懸案でないときの珍しいインスタンスを除いて、ほとんどのベンチマークで、SCl ソケットは TCP/IP に対しておよそ 100% パフォーマンスを改善することです。これはスキャンのフィルタが殆どのプロセス時間を使った場合あるいはプライマリ きーの非常に大きなバッチ アクセスが達成されたときに起こります。その様な場合、ndbd プロセスの CPU の処理がオーバーヘッドのかなり大きな部分になります。

SCI ソケットの代わりに SCI トランスポートを使用するには、ndbd プロセス間の通信の端に興味によるものです。SCI トランスポーターを使用するのも単なる興味からで、SCl トランスポーターがこのプロセスが決して停止しないことを確認するため、CPU を ndbd プロセスに専用にできるかとの単なる興味からのものです。ndbd プロセスの優先権がプロセスが、Linux 2.6 でプロセスをロックできるように、時間を延長して実行されても優先権がなくならないように設定されているか確認する必要があります。そのような設定が可能な場合、ndbd プロセスは SCI ソケットを使用した場合に比べて 10–70% 恩恵があることになります。(更新および並列スキャンのオペレーションでは大きな数字になります。)

コンピュータのクラスタに Myrinet、ギガビット Ethernet、Infiniband および VIA インターフェースなど他にもいくつかの最適化ソケットの実装があります。これまでに MySQL Cluster を SCI ソケットだけでしかテストしていません。通常の TCP/IP を MySQL Cluster 使用した SCI ソケットの設定方法については、項14.12.1. 「SCI ソケットを使用するための MySQL Cluster の設定」 を参照してください。