Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  memcached のハッシュ化/分布タイプ

16.6.2.4 memcached のハッシュ化/分布タイプ

memcached クライアントインタフェースは、特定の memcached インスタンスのデータを設定または取得するときにどのホストを使用すべきかを決定するため、マルチサーバー構成で使用される異なる分布アルゴリズムをサポートします。値を取得または設定すると、指定されたキーからハッシュが作成され、構成済みサーバーのリストからホストを選択するために使用されます。ハッシュ化メカニズムは指定されたキーをハッシュのベースとして使用するため、設定操作と取得操作の両方で同じサーバーが選択されます。

このプロセスは次のように考えることができます。一連のサーバー (a、b、および c) があり、クライアントは格納または取得されるキーに基づく整数を返すハッシュ化アルゴリズムを使用します。生成された値を使用して、クライアントに構成されたサーバーリストからサーバーが選択されます。memcache クライアント内のもっとも標準的なクライアントハッシュ化では、構成された memcached サーバーの数で値を割る簡単なモジュラス計算が使用されます。このプロセスは、擬似コードで次のように要約できます。

@memcservers = ['a.memc','b.memc','c.memc'];
$value = hash($key);
$chosen = $value % length(@memcservers);

上記を値で置き換えると:

@memcservers = ['a.memc','b.memc','c.memc'];
$value = hash('myid');
$chosen = 7009 % 3;

上の例では、クライアントのハッシュ化アルゴリズムによってインデックス 1 (7009 % 3 = 1) のサーバーが選択され、そのサーバーでキーと値が格納または取得されます。

注記

この選択とハッシュ化のプロセスは、使用している memcached クライアントによって自動的に処理されます。ユーザーは使用する memcached サーバーのリストを提供するだけで済みます。

次の図16.5「memcached のハッシュ選択」は、これをグラフィカルに表現したものです。

図 16.5 memcached のハッシュ選択

memcached のハッシュ選択

同じハッシュと選択のプロセスは、memcached クライアント内の指定されたキーの操作で実行されます。

この方法を使用することで、いくつかのメリットが得られます。

  • 接続するサーバーのハッシュ化と選択がクライアントの内部で完全に処理されます。これにより、接続する正しいマシンを決定するためにネットワーク通信を行う必要がなくなります。

  • memcached サーバーの決定がクライアントの内部で完全に行われるため、実行される操作 (設定、取得、増分など) に関係なくサーバーを自動的に選択できます。

  • この決定はクライアント内で処理されるため、ハッシュ化アルゴリズムは特定のキーに対して同じ値を返します。サーバー環境の違いによって値が影響を受けたり、リセットされたりすることはありません。

  • 選択は非常に高速です。キー値に対するハッシュ化アルゴリズムは高速であり、その結果、使用可能なマシンの単純な配列からサーバーが選択されます。

  • クライアント側のハッシュ化を使用することで、各 memcached サーバー間のデータの分布が簡略化されます。ハッシュ化アルゴリズムによって返される値の自然な分布では、使用可能なサーバー間でキーが自動的に分散されます。

クライアント内で構成されているサーバーリストが同じままであれば、格納されている同じキーによって同じ値が返されるため、同じサーバーが選択されます。

ただし、同じハッシュ化メカニズムを使用しないと、同じデータが別のインタフェースによって別のサーバーに記録され、memcached の領域が無駄になるだけでなく、情報の相違につながる可能性があります。

注記

マルチインタフェース互換のハッシュ化メカニズムを使用する 1 つの方法は、libmemcached ライブラリと関連インタフェースを使用することです。異なる言語 (C、Ruby、Perl、および Python を含む) のインタフェースが同じクライアントライブラリインタフェースを使用するため、ID から常に同じハッシュコードが生成されます。

クライアント側でサーバーを選択する場合の問題は、memcached サーバーを使用する各クライアントでサーバーリスト (それらの順番を含む) の整合性を維持し、それらのサーバーを使用可能にしておく必要があることです。次のときに、キーに対して操作を実行しようとする場合:

  • 使用可能なインスタンスのリストに新しい memcached インスタンスを追加した

  • 使用可能なインスタンスのリストから memcached インスタンスを削除した

  • memcached インスタンスの順序が変更された

特定のキーに対してハッシュ化アルゴリズムが使用されるときにサーバーリストが異なる場合は、ハッシュ計算によってリストから別のサーバーが選択される可能性があります。

次の例の new.memc のように、サーバーリストに新しい memcached インスタンスが追加された場合は、同じキー (myid) を使用する GET 操作によってキャッシュミスが発生します。これは、このキーから同じ値が算出され、サーバーの配列から同じインデックスが選択されるが、インデックス 2 はデータが本来格納されているサーバー c.memc ではなく新しいサーバーを指すようになったためです。このため、別の memcached インスタンスのキャッシュにそのキーが存在するにもかかわらず、キャッシュミスが発生します。

図 16.6 新しい memcached インスタンスを含む memcached のハッシュ選択

新しい memcached インスタンスを含む memcached のハッシュ選択

これは、c.memcnew.memc の両方にキー myid の情報が含まれることを意味しますが、このキーに対して各サーバーに格納される情報は各インスタンスで異なる可能性があります。より重要な問題は、新しいサーバーによってキーの分布が変わるにつれて、データ取得時のキャッシュミスの数が大幅に増加することです。さらに、この結果として memcached インスタンスにキャッシュされているデータを再構築する必要があるため、データベースの読み取り回数が増加します。

クライアントに構成されているサーバーリストをアクティブに管理し、構成済みの memcached インスタンスが使用可能として識別されたときに各インスタンスを追加および削除する場合も、同じ結果になる可能性があります。たとえば、ある memcached インスタンスが接続できなくなったことをクライアントが検出したときにそのインスタンスを削除すると、ここに示したようにサーバーの選択が失敗する可能性があります。

これによって重大な問題が発生してキャッシュが無効になることを防ぐため、サーバーの選択に使用するハッシュ化アルゴリズムを選択できます。ハッシュ化アルゴリズムには、整合モジュラの 2 つの一般的なタイプがあります。

整合ハッシュ化アルゴリズムでは、構成済みサーバーのリストが変更された場合でも、同じキーをサーバーリストに適用すると、同じサーバーを使用してキーが格納または取得されます。これは、構成リストのサーバーを追加および削除しながら、特定のキーに対して常に同じサーバーを使用できることを意味します。使用可能な整合ハッシュ化アルゴリズムには、Ketama と Wheel の 2 つのタイプがあります。どちらのタイプも libmemcached によってサポートされ、PHP および Java 用の実装が入手可能です。

整合ハッシュ化アルゴリズムにはいくつかの制限があります。既存の構成済みサーバーのリストにサーバーを追加すると、通常の分布の一部として新しいサーバーにキーが分配されます。リストからサーバーを削除すると、そのキーはリスト内の別のサーバーに再割り当てされるため、キャッシュに情報を再度移入する必要があります。また、整合ハッシュ化アルゴリズムでは、複数のクライアント間でサーバーを一貫して選択する必要があるにもかかわらず、各クライアントに異なるサーバーリストが含まれているという問題は解決されません。整合性が適用されるのは、1 つのクライアントの内部だけです。

モジュラハッシュ化アルゴリズムでは、クライアントはハッシュを計算して構成済みサーバーリストからサーバーを選択することにより、サーバーを選択します。サーバーリストが変わると、モジュラハッシュ化アルゴリズムを使用して選択されるサーバーも変わります。この結果、前述の動作が発生します。サーバーリストの変更は、データの取得時に別のサーバーが選択されることを意味し、キャッシュに情報が再移入されるため、キャッシュミスとデータベース負荷の増大につながります。

各クライアントで memcached インスタンスを 1 つだけ使用する場合や、クライアントに構成された memcached サーバーのリストが一度も変更されていない場合は、ハッシュ化アルゴリズムの選択による大きな効果もないため、重要ではありません。

サーバーを定期的に変更する場合や、多数のクライアントで共有される共通のサーバーセットを使用する場合は、整合ハッシュ化アルゴリズムを使用することで、確実にキャッシュデータの重複を防ぎ、データを均等に分配しやすくなります。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.