0

より良い解決策を探しています。

私は 200.000 人以上のユーザーと膨大な量の SQL クエリを持つコミュニティを手に入れました。それらのほとんどには、結果にユーザー ID が含まれています。ほとんどの場合、出力時に関連するユーザー名を使用して回避する必要があります。

[userId - username] は別のテーブルです。このテーブルへの大量の JOINS を避けるために、ホール テーブルを memcacheD の配列としてキャッシュすることにしました。それは最初はうまくいきました。SQL サーバーの負荷が大幅に低下しました。すべてが以前よりも本当に速く実行されます。

しかし、数週間後、ホール サーバー クラスター (5 Web サーバー) に問題が発生しました。キャッシュされた userid-username データセットは巨大になります。memcacheD がそのレコードを要求サーバーに送信している間に、ネットワーク インターフェイスで内部の 1000Mbit データ制限に達したほどです。データをシリアル化しようとしましたが、戦利品は変わりませんでした。

私は今行くべき3つの方法を考えています：

1) memcacheD がすべてのサーバーでレコードをキャッシュするように強制します。したがって、クラスターは別のサーバーからキャッシュを要求する必要はありません。ただし、データセットのすべての変更は、すべてのサーバーで同時に行う必要があります。-とにかく、それが可能かどうかはわかりません。

2) JOINS に戻り、cacheexecute を使用します。

3）より良い解決策があります！:)

4

1 に答える 1

0

意図しない方法でキャッシュを使用しているようです。Memcached は、単一の大きなデータ要素を格納する場所ではなく、キーと値のストアとして使用するのに最適です。個々の呼び出しごとにこの配列全体が実際に必要なのか、それともデータ アクセス パターンを再設計して、要求を満たすために必要なデータを取得するだけなのかについて、私は本当に考えます。つまり、ユーザー名があり (たとえばログインから)、ユーザー ID を取得する必要がある場合は、そのユーザー名でキー検索を実行して、必要なユーザー ID のみを取得します。

ただし、この種のシナリオでは、ユーザー ID/ユーザー名のデータを Memcached に保持することで得られるものはよくわかりません。同じユーザー ID が繰り返しヒットして、データをキャッシュに保持することのメリットを本当に最大化するケースはありますか? このデータをディスクではなく、ある種のデータ永続化レイヤーのメモリに保存することの揮発性について心配していませんか?

より具体的なアドバイスを提供するには、ユースケースについてもっと理解する必要があると思いますが、データの配列全体を保存して取得しようとするのは非常に奇妙に思えます。

于 2013-01-11T17:53:38.677 に答える