多くの場合「表示」されるように設計されたページを作成しますが、データベースに「書き込む」ユーザーははるかに少なくなります。たとえば、自分のニュースを自分のサイトに投稿できるユーザーは 100 人に 1 人だけで、残りはニュースを読むだけです。
上記の場合、実際のデータベースの変更はほとんどありませんが、彼らが私のホームページにアクセスすると、100 件の同じクエリが実行されます。実際、これらのクエリの 99 は、コンピューターの能力の浪費です。最初のクエリの結果をキャッシュし、同じクエリを短時間で検出したときに、キャッシュされた結果を配信できるメソッドはありますか?
MongoDB と Tornado を使用しています。ただし、MongoDB はキャッシングを行わないという投稿もあります。
Tornado で毎回パーソナライズされたページをレンダリングしたいので、Nginx のようなもので静的なキャッシュ HTML を作成することはお勧めしません。
MongoDB と Tornado を使用しています。ただし、MongoDB はキャッシングを行わないという投稿もあります。
誰が言ったかはわかりませんが、MongoDB にはクエリをキャッシュする方法があります。実際、メモリ管理自体を行わないため、OS の LRU を使用してキャッシュします。
OS が常にページアウトしたりスワップしたりする必要がなく、作業セットが LRU に収まる限り、ほとんどの場合、このクエリをメモリから読み取る必要があります。はい、MongoDB はキャッシュできますが、技術的にはできません。OSが行います。
実際、これらのクエリの 99 は、コンピューターの能力の浪費です。
この種の問題を解決するためのキャッシング メカニズムは、MongoDB によるものであろうと SQL によるものであろうと、ほとんどの技術者で同じです。もちろん、これは問題がある場合にのみ重要です。私に尋ねると、おそらくマイクロ最適化です。Facebook、Google、または Youtube のようなトラフィックが発生しない限り。
キャッシングの問題は、事前に集約された MongoDB/Memcache/Redis などでクエリをキャッシングすることから、HTML やその他の Web リソースをキャッシングして、サーバー側での作業をできるだけ少なくすることまで、大きな問題になります。
あなたのシナリオは、私が個人的に言ったように、無駄なコンピューター パワーについて間違った考えをしているように聞こえます。このクエリを別のコレクション/技術にキャッシュしたとしても、その技術から結果を取得するために、気にしない場合と同じ量の電力とリソースを使用することになるでしょう。ただし、その前提は、適切なインデックス、スキーマ、セットアップなどを持っていることに帰着します。
優れたスキーマ設計とインデックス作成に関するリンクを読むことをお勧めします。
Tornado で毎回パーソナライズされたページをレンダリングしたいので、Nginx のようなもので静的なキャッシュ HTML を作成することはお勧めしません。
ええ、クエリのキャッシュについて心配しようとすると、特に離陸したくない場合は、時期尚早に最適化されていると思います。毎回サーバーの負荷の 90% になるでしょう。ページ自体をロードします。
スキーマとインデックスに焦点を当て、本当に必要な場合はキャッシュについて心配します。
Motor (MOngo + TORnado) パッケージの作成者は、ここでカテゴリのリストをキャッシュする例を示しています: http://emptysquare.net/blog/refactoring-tornado-code-with-gen-engine/
基本的に、彼はカテゴリのグローバル リストを定義し、データベースにクエリを実行して入力します。次に、ページにカテゴリが必要なときはいつでもリストをチェックします。存在する場合はそれを使用し、存在しない場合は再度クエリを実行して入力します。データベースに挿入するたびにリストを無効にするように設定しています。 、ただし、使用状況に応じて、グローバル タイムアウト変数を作成して、次に再クエリが必要な時期を追跡できます。複雑なことをすると手が出ないかもしれませんが、最近の投稿の一覧などであれば問題ないと思います。