InnoDB を memcached と組み合せて使用すると、すぐに行うか後で行うかにかかわらず、すべてのデータをディスクに書き込む必要があるため、RAW パフォーマンスはそれ自体で memcached を使用するより多少遅くなることが予想されます。 InnoDB memcached プラグインを使用する場合、同等の SQL 操作よりも優れたパフォーマンスを実現するために、memcached 操作のチューニング目標に焦点を当てます。

ベンチマークは、memcached インタフェースを使用するクエリーおよび DML 操作 (挿入、更新および削除) が従来の SQL より高速であることを示しています。 DML 操作では、通常、改善点が大きくなります。 したがって、最初に memcached インタフェースを使用するように書込み集中型アプリケーションを調整することを検討してください。 また、信頼性のない高速で軽量なメカニズムを使用する書込み集中型アプリケーションの適応に優先順位を付けることも検討してください。

SQL クエリーの改変

単純な GET リクエストに最も適したクエリーのタイプは、WHERE 句に単一の句または AND 条件のセットを含むクエリーです:

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_buffer_pool_size 構成オプションを使用して、システム RAM の大部分が InnoDB buffer pool 専用である一般的なデータベースサーバーとして構成されているマシンに daemon_memcached プラグインをデプロイします。 マルチギガバイトバッファプールがあるシステムでは、ほとんどの操作にすでにメモリーにキャッシュされているデータが含まれる場合、スループットを最大化するために innodb_buffer_pool_instances の値を増やすことを検討してください。

冗長 I/O の削減

InnoDB には、高い信頼性 (クラッシュの場合) と高い書込みワークロード中の I/O オーバーヘッドの量のバランスを選択できる多数の設定があります。 たとえば、innodb_doublewrite を 0 に、innodb_flush_log_at_trx_commit を 2 に設定することを検討してください。 様々な innodb_flush_method 設定でパフォーマンスを測定します。

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

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

daemon_memcached_r_batch_size および daemon_memcached_w_batch_size のデフォルト値の 1 は、格納または更新されたデータの結果の信頼性と安全性を最大限に高めるためのものです。

アプリケーションのタイプによっては、これらの設定の 1 つまたは両方を増やすと、頻繁なコミット操作によるオーバーヘッドを削減できる場合もあります。 ビジー状態のシステムでは、SQL を介して行われたデータへの変更が memcached にすぐに表示されないことを知っている (つまり、N の get 操作がさらに処理されるまで) daemon_memcached_r_batch_size を増やすことができます。 すべての書込み操作を確実に格納する必要があるデータを処理する場合は、daemon_memcached_w_batch_size を 1 に設定したままにします。 統計分析のみを目的とした大量の更新を処理する場合は、予期しない終了での最後の N 更新の消失が許容されるリスクである設定を増やします。

たとえば、ビジーブリッジを通過するトラフィックを監視し、毎日約 100,000 台の車両のデータを記録するシステムについて考えてみます。 アプリケーションがトラフィックパターンを分析するために様々なタイプの車両をカウントする場合、daemon_memcached_w_batch_size を 1 から 100 に変更すると、コミット操作の I/O オーバーヘッドが 99% 削減されます。 停止の場合、最大 100 個のレコードが失われます。これはエラーの許容マージンである可能性があります。 かわりに、アプリケーションが自動車ごとに自動通話回収を実行した場合は、daemon_memcached_w_batch_size を 1 に設定して、各通話レコードがすぐにディスクに保存されるようにします。

InnoDB が memcached キー値をディスク上に編成する方法のため、作成するキーが多数ある場合は、キーを任意の順序で作成するよりも、アプリケーションのキー値でデータ項目をソートし、add をソート順でソートする方が高速な場合があります。

通常の memcached ディストリビューションの一部であるが、daemon_memcached プラグインには含まれていない memslap コマンドは、異なる構成をベンチマークする場合に役立ちます。 また、独自のベンチマークで使用するサンプルのキーと値のペアを生成するためにも使用できます。 詳細は、libmemcached Command-Line Utilitiesを参照してください。