2

このテーマについていくつか読んだこと：

MySQL クエリのキャッシュ

http://www.danga.com/memcached/

私の SQL キャッシングの問題: http://www.petefreitag.com/item/390.cfm

http://framework.zend.com/manual/en/zend.cache.html#zend.cache.introduction

私は非常にユニークな (狭い) クエリのセットを持っており、現在の FastCGI C API 実行可能ファイル (PHP ではない) 内でキャッシュを簡単に実装できると思います。

Zend はそのフレームワークを次のように説明しています。キャッシュ レコードは、ID とタグの柔軟なシステムを通じて、バックエンド アダプター (ファイル、Sqlite、Memcache...) を介して保存されます。

これはどのように実装されていますか？

テーブルが変更された場合、同じクエリが異なる結果を返す可能性があるため、クエリだけでなく、UPDATE、INSERT、および DELETE も監視する必要があります (今のところ MySQL)。これはプロセスの 1 つからのみ発生するため、簡単に追加できます。テーブルの変更時にキャッシュを削除するステートメント。

クライアントが許可するのは SELECT のみです。この場合、クエリをハッシュして、結果を含むファイルへのポインターと共にハッシュ テーブルまたは Btree インデックスに格納できます。

より良い方法はありますか？

4

3 に答える 3

1

ああ、それは良い質問です。私は .NET 開発者として、幸運にも過去 7 年間、この問題についてまったく心配する必要がありませんでした。.NET は非常に強力なキャッシング メカニズムを実装しているため、心配する必要はありません。

中間層またはプレゼンテーション層でこれを行う方法はありませんか?

于 2008-11-24T01:28:19.237 に答える
1

.NET は迅速な開発には確かに便利ですが、MS が耳の聞こえない仲間になるため、望ましくない結果が生じます。

また、ニーズに合わせて調整できるため、独自のソリューションを開発することも好みます。サーバー側でインバウンドクエリを結果セットに結び付けるメカニズムだけで、洗練されたものはあまり必要ありません。プレゼンテーションは、別のデータベースが存在するクライアント側で行われます。リクエストは実際にはクライアント側のデータベースを更新するだけなので、質問への回答として、クライアント側のキャッシュはすでに実装されています。

于 2008-11-24T11:29:50.847 に答える
0

これについて考えると、結果をディスクにキャッシュする方が高速ですが、ディスクの負荷が大幅に増加することに気付きます。私の場合、DB はクエリに対してそれほど遅くはありません。最大の問題は結果セットに必要なメモリであり、結果セットあたり最大 3MB です。xferの進行中にすべてをメモリに保持すると、サーバーのメモリがすぐに使い果たされます

于 2008-11-24T22:07:54.023 に答える