Djangoでキャッシュするときの共通のパターンは、各キャッシュキーで現在のサイトのIDを使用することです。私が持っている問題は、すべてのの名前空間のキャッシュ内の値を削除できることです(たとえば、基本的な変更を行ったため、サイト45のキャッシュ値をすべて削除することができます)。これを処理するための現在のパターンはどこにでも送信されます。私はSite.id
キャッシュキーの例を使用しました。これは他の人が認識できる共通のパターンだからですが、カスタムマルチテナントアプリケーションはこの問題をさらに深刻にしています。私の質問:名前空間や疑似名前空間のオブジェクトを削除するのにうまく機能するキャッシュバックエンドやパターンがありますか?特定の名前空間のすべての可能なキャッシュキーを通して、それぞれのキャッシュを削除します)。私はmemecachedを使用することを好むでしょうが、プラグインの有無にかかわらず、うまく動作するすべてのソリューションを公開しています。Django/generalキャッシングに関する質問
1
A
答えて
2
大きなカテゴリのキーを削除することは一般的には難しいです。より良いアプローチは、各サイトがそれに関連付けられた世代番号を持つことです。 1で世代を開始します。そのサイトのキャッシュキーで世代番号を使用します。基本的な変更を行う場合や、サイトのキャッシュ全体を無効にする場合は、サイトの世代番号を増やします。すべてがキャッシュされるまで、すべてのキャッシュアクセスはミスになります。古いデータはすべてキャッシュに残っていますが、古くなると破棄され、それ以上アクセスされません。
このスキームは、古いデータをすべて見つけたり触れたりする必要がないため、非常に効率的です。また、あらゆる種類のキャッシュコンテンツにも一般化することができ、サイトごとにする必要はありません。
1
私は、DjangoのがDjango 1.3の新機能であると感じています。
それはあなたがあなたのキャッシュにシステム全体の変数VERSION
を設定することができ、またはレコードを作成するときに明示的に設定することができます。
cache.set("mykey", True, version=2)
この方法では、あなたのキャッシュを更新する必要がある場合、単にあなたのVERSION
をアップして、あなたは明らかです。
+0
ありがとうございます。 Nedの回答に対するコメントを参照してください。 – orokusaki
関連する問題
- 1. HTTPキャッシングの質問
- 2. フラッシュに関する質問
- 3. インデックスに関する質問
- 4. dbms_stats.gather_table_statsに関する質問
- 5. リフレクションパッケージに関する質問
- 6. nthに関する質問
- 7. initWithNibNameに関する質問
- 8. タブバーコントローラに関する質問
- 9. データベースに関する質問
- 10. CCSpriteSheetに関する質問
- 11. Msbuildに関する質問
- 12. インテントサービスに関する質問
- 13. BSplineに関する質問
- 14. データベースに関する質問
- 15. ModelMultipleChoiceFieldに関する質問
- 16. Erlangに関する質問
- 17. loadNibNamedに関する質問:
- 18. データバインディングに関する質問
- 19. コンビナトリアルに関する質問
- 20. APIに関する質問
- 21. presentModalViewControllerに関する質問
- 22. gridfsに関する質問
- 23. ハイバネートマッピングに関する質問
- 24. プロセスマップに関する質問
- 25. セマフォに関する質問
- 26. メイクファイルに関する質問
- 27. ostrstreamに関する質問
- 28. @propertyに関する質問
- 29. Masterpagesに関する質問
- 30. C++に関する質問
これはコードの変更には有効ですが、キャッシュのバージョンを制御するためにデータ変更のDBレコードを保持しない限り、データの変更には使用できません。したがって、ユーザーが広範囲にわたるデータ変更を引き起こすものを変更した場合、変更の記録を作成せずにキャッシュバージョンを増やすことはできません。 – orokusaki
右、サイトIDと世代番号を持つdbテーブルがあります。問題ありますか?実際、最良のシステムはコード内の定数とデータベース内の値を持ち、一緒にキャッシュ接頭辞を決定します。どちらか一方が変更されると、キャッシュは無効になります。 –