14.18.5.3 InnoDB memcached プラグインのパフォーマンスのチューニング

InnoDB と memcached を組み合わせて使用すると、すべてのデータを即座にまたはしばらくしてからディスクに書き込むため、パフォーマンスが、memcached のみを使用する場合よりも若干低くなります。InnoDB memcached プラグインのチューニングでは、同等の SQL 操作よりも高いパフォーマンスを達成するよう設定してください。

ベンチマークでは、クエリーおよび DML 操作 (挿入、更新、および削除) は両方とも、従来の SQL よりも memcached インタフェースを経由した方が高速になります。通常は DML 操作の方が速度が大きく向上します。したがって、memcached インタフェースを使用するために最初に改変した方がよいアプリケーションのタイプは、書き込み処理の多いアプリケーションです。また、以前信頼性が優先されていなかった場合、高速かつ軽量なメカニズムを使用した書き込み処理の多いアプリケーションタイプでは、MySQL をデータストアとして使用する場合もあります。

SQL クエリーの改変

単純な GET リクエストスタイルのもっとも適合するクエリーのタイプは、単一句または AND 条件のセットを WHERE 句に指定したものです。

SQL:
select col from tbl where key = 'key_value';

memcached:
GET key_value

SQL:
select col from tbl where col1 = val1 and col2 = val2 and col3 = val3;

memcached:
# Since you must always know these 3 values to look up the key,
# combine them into a unique string and use that as the key
# for all ADD, SET, and GET operations.
key_value = val1 + ":" + val2 + ":" + val3
GET key_value

SQL:
select 'key exists!' from tbl
  where exists (select col1 from tbl where key = 'key_value') limit 1;

memcached:
# Test for existence of key by asking for its value and checking if the call succeeds,
# ignoring the value itself. For existence checking, you typically only store a very
# short value such as "1".
GET key_value

システムメモリーの利用

最適なパフォーマンスを得るには、InnoDB memcached プラグインを、典型的なデータベースサーバーのように構成されたマシン上に配備し、特に、innodb_buffer_pool_size 構成オプションを使用して、大部分のシステム RAM を InnoDB バッファープールに割り振ったデータベースサーバー上に配備します。複数ギガバイトのバッファープールを備えたシステムで、ほとんどの操作がメモリーにキャッシュされているデータを使用する場合、スループットが最大になるように innodb_buffer_pool_instances 構成オプションの値を高くします。

冗長 I/O の削減

InnoDB には、クラッシュ時の高い信頼性と、高書き込みワークロード時の I/O オーバーヘッドの量とのバランスを選択できる設定があります。たとえば、構成オプション innodb_doublewrite=0 および innodb_flush_log_at_trx_commit=2 を設定します。innodb_flush_method オプションの設定を変えて、パフォーマンスを測定します。サーバーのバイナリログがチューニングされていない場合、innodb_support_xa=0 の設定を使用します。

テーブル操作の I/O を削減したりチューニングしたりするその他の方法については、セクション8.5.7「InnoDB ディスク I/O の最適化」を参照してください。

トランザクションオーバーヘッドの削減

構成オプション daemon_memcached_r_batch_size および daemon_memcached_w_batch_size に対するデフォルト値 1 では、結果に対する最大限の信頼性と、保管または更新されるデータの安全性を確保します。

アプリケーションのタイプによっては、これらの設定の 1 つまたは両方を増やすと、頻繁なコミット操作によるオーバーヘッドを削減できる場合もあります。データ処理の多いシステムでは、SQL を介して行なったデータへの変更が memcached に即座に (つまり、get 操作があと N 回処理されるまで) 表示されなくなることを確認し、daemon_memcached_r_batch_size を増やすこともできます。すべての書き込み操作を確実に保管する必要があるデータ処理の場合、daemon_memcached_w_batch_size の設定は 1 のままにします。統計分析にのみ使用する大量の更新を処理する場合は、クラッシュ時に最後の N 回の更新が失われても大きな問題はないため、この設定を増やすこともできます。

たとえば、通行量の多い橋を渡る交通量をモニターし、1 日に約 100,000 台の車両を記録するシステムについて考えてみます。交通パターンを分析するために、単に異なるタイプの車両を数えるだけのアプリケーションの場合、daemon_memcached_w_batch_size を 1 から 100 に変更すると、コミット操作の I/O オーバーヘッドを 99% 削減できます。予想外の機能停止の場合、最大 100 件のレコードが失われても、許容誤差の可能性があります。一方、各車両に対する自動料金徴収をアプリケーションで実行している場合、daemon_memcached_w_batch_size の設定を 1 のままにし、料金徴収の記録を即座にディスクに保存する方がよい場合もあります。

InnoDB がディスク上で memcached キー値を編成する方法が原因で、大量のキーが作成される場合、データ項目をアプリケーション内でキー値でソートし、ソートした順序で追加した方が、任意の順序でキーを作成するよりも高速になります。

memslap コマンドは、さまざまな構成のベンチマークで便利です。これは通常の memcached 配布の一部ですが MySQL Server に含まれていません。また、独自のベンチマークで使用できるサンプルのキー/値のペアの生成に使用できます。詳細は、セクション16.6.3.3.6「libmemcached のコマンド行ユーティリティー」を参照してください。