わかったので、memcached を使った作業の核心にはまだ触れていません。ハッキングを開始して何かひどいものを作る前に、memcached ソリューションをどのように実行するかについてブレインストーミング/計画を立てているからです。
環境は次のとおりです。Web サイトには、取引の人気度 (大きなグリッドを考えてください) で並べ替えられた、さまざまなベンダーからの取引のリストが表示されます。非ユーザーには常に同じグリッドが表示されますが、お気に入りのベンダーからの取引が常に最初に表示されるように、ユーザーはお気に入りのベンダーを選択できます。
現在の動作: 非ユーザーがサイトを開くと、テーブルからすべての取引情報を取得するために SQL クエリが送信さdealsれ、ページに必要な html を設定するために使用されます。ユーザーがサイトに入ると、もう少し高度な SQL クエリ (基本的にはdealsとの左結合userfavorites) が送信され、上記のように取引が注文され、html に入力されます。
私がしたいこと: 明らかに、dealsテーブルが更新されるまで常に同じであるため、非ユーザー SQL クエリは memcached に最適なようです (memcached バージョンを同時に更新できると思います)。ただし、ユーザーはお気に入りに対してさまざまなバリエーションを用意する予定であるため、ユーザー向けのキャッシュ ソリューションについてもどうすればよいか考えています。ユーザーが見るすべてのデータは、非ユーザーとまったく同じです。唯一の違いは順序です。キャッシュで既に利用可能なデータに対してクエリを実行することは、私には無意味に思えます。dealsと をキャッシュしてからuserfavorites (where userid=?)、PHP を使用して人為的に左結合と順序付けアクションを実行することは可能でしょうか?
要するに、こういうこと？
memcached version of deals (desc order by pageviews)
memcached version of favorites (specific to the user)
favoritecount = 0
for i = 0, i < length(deals), i++
if deals.i.vendor is a member of favorites
push deals.i to deals.favoritecount
favoritecount++
else
continue
は既にソートされており、順次処理されているため、これについて正しく考えている場合、これにより∪dealsの形式で取引リストが生成され、これを使用して html を吐き出すことができます。favorites (desc order by pageviews)deals (desc order by pageviews)
もちろん、ユーザーがお気に入りを追加または削除した場合に、キャッシュされたバージョンが更新されるようにチェックすることもできます。
皆さんはどう思いますか？これは可能ですか？ほとんど同じデータの場合、ユーザーがデータベースにできるだけ触れないようにしたいので、memcached を使用して、上記で説明したことを実行できるようにしたいと考えています。現時点では、ウェブサイトへのすべてのヒットがデータベースにアクセスしています。これをお読みいただきありがとうございます。ご意見をお待ちしております。