2009-08-24 8 views
1

私は複数のユーザーに対して複数のアイテムを計算するために必要な「スコア」を持っています。各ユーザーには、独自の多数のスコアがあり、計算には時間/プロセッサを集中させることができます。 (遅さはデータベースの最後ではありません)。これに対処するために、私はmemcachedを広く使用しています。 memcacheを使用しないと、ロードに10秒かかることがあります。 Memcacheはスコアが非常に小さい情報であるため計算に時間がかかるため、うまくいくように見えます。私は実際にはキーが期限切れにならないように設定しています。そして、スコアが変わることもあります。この方法でmemcacheを使用することはできますか?システムの再構築が必要か?

私はこの製品に新しい段階を踏み出しており、全体を再設計することを検討しています。値を繰り返し計算してローカルのフィールドに格納する方法があるようです。それは今起こっていることにちょっと似ているでしょう。価値の更新はより速く起こり、キャッシュは実際のデータベースにあり、それを管理することはもう少し作業になります(私はまだmemcacheを使いますそれでも)。

重要なのは、すべてpython/djangoです。

この悪い習慣のようにキャッシュに入れようとしていますか?大丈夫ですか?どうして?私は物事を再構築しようとするべきですか?

答えて

2

破損していない場合は...修正しないでください。^)あなたの方法が機能しているようですので、それに固執すると思います。 memcacheの永続的なバージョンであるmemcachedb(またはtokyo cabinet)を見るかもしれません。このようにして、memcacheマシンがクラッシュして再起動すると、すべての値を再計算する必要はありません。

1

ここではいくつかのアーキテクチャパターンを適用していますが、それぞれには確かに場所があります。現在のソリューションで再構築が必要かどうか、またはアイデアが機能するかどうかを評価するのに十分な情報はここにありません。ユーザーの要件を理解していくにつれて、物事を改善したいと思うかもしれません。

いつもと同じように、プロトタイプ、測定パフォーマンス、複雑さとパフォーマンスのトレードオフを考慮してください。できるだけ速くする必要はありません。

多くの場合、さまざまな形式でキャッシュすることが、優れたパフォーマンスの鍵です。ここでの質問は、caclulated、cahced値を維持することにメリットがあるかどうかです。時間が経っても安定していれば、これはしばしば効果的な戦略です。キャッシュを永続化するか、データベーススキーマ内にスペースを確保するかは、おそらくアクセスパターンに依存します。私はさまざまなクエリのパスがあり、慎重に設計されたデータベーススキームが適切かもしれません。

0

memcachedを使用するのではなく、計算されたスコアを他のデータと同じ場所に保存してみてください。これはより簡単であり、必要なボックス数はより少なくてもよい。

Memcachedは必ずしもすべての回答ではありません。非常に高度に読み込みを行う必要があるシステムを対象としています。それはあなたの場合のように聞こえる、それは必要ない、ちょっとだけより効率的である必要がある。

関連する問題