6

memcached と従来の memcached-object-read-with-sql-server-fallback を使用するファンタジー フットボール アプリケーションがあります。これはかなりうまく機能しますが、最近、関連するオーバーヘッドと、これが最善のアプローチであるかどうかを考えています。

適切な例 - ユーザー チームのドロップダウン リストを生成する必要があるため、次のパターンに従います。

  1. memcached からユーザー チームのリストを取得する
  2. 利用できない場合は、SQL サーバーからリストを取得し、memcached に保存します。
  3. マルチゲットを実行して、チーム オブジェクトを取得します。
  4. これらの SQL ストアからのオブジェクトの読み込みにフォールバックします。

これはまったく問題ありません。キャッシュされた各データは比較的簡単にキャッシュおよび無効化されますが、これには 2 つの大きな欠点があります。

1) オブジェクトを操作しているため、かなり大きなオーバーヘッドが発生しています。1 つのチームが memcached で数百バイトを占めており、この場合に本当に必要なのはチーム名と ID のリストだけです。チーム オブジェクト。

2) 個々のオブジェクトをロードするためのフォールバックのため、空のキャッシュまたはアイテムの有効期限が切れたときに生成される SQL クエリの数は膨大になる可能性があります。 WHERE Id IN (...) 20 x Store in memcached したがって、この 1 つのクエリだけで 21 のネットワーク リクエストが発生し、IN クエリは特定の結合よりも遅くなります。

明らかに、単純なことを行うことができます

SELECT Id, Name FROM Teams WHERE UserId = XYZ

その結果をキャッシュしますが、これは、ユーザーが新しいチームを作成するたびに、このデータを明確に無効にする必要があることを意味します。この場合、比較的単純に見えるかもしれませんが、これらのタイプのクエリの多くがあり、それらの多くは簡単に無効化されない軸で動作します (友人が特定の場所で作成したチームの ID と名前のリストなど)。ゲーム）。

すっごく..私の質問は-言及された欠点を解決するためのアイデアを持っている人はいますか、それともオーバーヘッドがあり、キャッシュミスが悪いことを受け入れる必要がありますか?

4

2 に答える 2

0

まず、完全なレコードではなく、必要なもの、おそらくその 2 つのフィールドをキャッシュします。

次に、必要なものを再度キャッシュし、結果セットをレコードに分割して個別にキャッシュします

于 2013-03-27T02:18:10.033 に答える
0

キャッシングについて:

一般に、キャッシングを使用して低速のディスクベースのストレージ (この場合は mysql) をオフロードします。メモリ キャッシュはかなり簡単にスケールアップしますが、mysql はそれほど簡単にはスケールアップしません。

そのため、キャッシュの CPU/ネットワーク/メモリの使用量を 2 倍にして、すべてを再びまとめても、データベースはオフロードされます。別の nodejs インスタンスまたは別の memcached サーバーを追加するのは簡単です。

あなたの質問に戻ります

  1. あなたはそれがユーザーのチームだと言い、ユーザーがログインしたときにそれをフェッチし、ユーザーがセッション中に変更している間、キャッシュで更新し続けることができます。

  2. チーム メンバーの名前は変わらないと思います。その場合、すべてのチーム メンバーを ID、名前でロードし、それらをキャッシュまたは nodejs のローカルに保存できる場合は、現在と同じフォールバック戦略を使用します。残りはステップ 1 と 2 と 4 だけです。

個人的に私は通常、SQLの結果を小さな既製の断片に分割してそれらをキャッシュし、キャッシュをできるだけ長く更新し続けようとします.mysqlをストレージとしてのみ使用し、そこから読み取らないようにします

通常、とにかくmysqlから返された行で何らかのロジックを実行しますが、それを繰り返し続ける必要はありません。

于 2013-12-17T22:06:45.817 に答える