Memcached scaling：key "grouping"

Question

頻繁に検索される（multiGetを使用して）関連するキーを単一のサーバーでグループ化してパフォーマンスを最適化することをお勧めします。クライアント機能によって使用される暗黙の仕組みに関するいくつかの質問がありますこれを行うために作られています。

私は、libmemcache（特にphp-memcached）を使用して同じ目的を果たしていると仮定して、2つの異なるアプローチを見てきました。最初の最も明白なアプローチは、キーをサーバーにマップするためにgetByKey/setByKeyを使用する方法と、OPT_PREFIX_KEYオプションを使用する方法です（memcached :: _ constructのPHPドキュメントに簡単な例が掲載されています）。あなたのアイテムキーのための 'ドメイン'を作成するために使用されます。第2のアプローチの注意点は、インスタンス単位でしか設定できないことです。これは良いことかもしれません。

私は完全に間違っていない限り、これらの2つのアプローチは実際には同じ目的を果たしません。それは他のものよりもアプローチを取っていく上で明確なメリットですか？

私はこのトピックについて話していますが、他にも質問があります。一貫してハッシュされたシナリオでキーをサーバーにマッピングすることにはどういう意味がありますか？私は、ノードが失敗した場合、フリーフォームのキーは問題なく新しいサーバーにリマップされると仮定しています。

ありがとう！

Answer 1

これらのキーがほぼ同時に検索される場合は、キーをソートして連結したり、辞書としてシリアル化された値をJSON形式または類似の形式で格納するなど、単一のキーと値のペアで一緒にキャッシュします。

あなたの質問に戻る：

• OPT_PREFIX_KEYがキーで値をグループ化を行うにはほとんど何も持っていない、それだけで、この特定のクライアントが使用するすべてのキーを接頭辞ので、「1」は「foo1の」となってから配布されますこの新しい値を使って一貫性のあるハッシングを行い、 "foo"によるグループ化は一切ありません。
• getByKey/setByKeyは、libketama（サーバーの選択に使用されたキー）とmemcachedサーバーに異なるキーを渡すことができるため、必要なものに最も近いものです。同じ最初のキーと異なる2番目のキーを指定すると、それらは同じmemcachedサーバーで終了しますが、お互いを上書きしません。

時期尚早の最適化は諸悪

のルートです