最新のデータベースは、キャッシュのサポートを提供します。ほとんどの ORM フレームワークは、取得したデータもキャッシュします。なぜこの重複が必要なのですか？
10378 次
9 に答える
44
データベースのキャッシュからデータを取得するには、次のことを行う必要があります。
- ORM の「ネイティブ」クエリ形式から SQL を生成する
- データベース サーバーへのネットワーク ラウンドトリップを実行する
- SQL を解析する
- キャッシュからデータをフェッチする
- データをデータベースの有線形式にシリアル化する
- データをデータベース クライアント ライブラリの形式に逆シリアル化する
- データベース クライアント ライブラリの形式を言語レベルのオブジェクト (つまり、何かのコレクション) に変換します。
アプリケーション レベルでキャッシュすることにより、そのようなことを行う必要はありません。通常、これはメモリ内のハッシュ テーブルの単純な検索です。ときどき (memcache を使用したキャッシュの場合) ネットワークのラウンドトリップが発生することがありますが、他のすべての処理は行われなくなります。
于 2010-06-03T06:55:37.443 に答える
12
これが必要な理由はいくつかあります。
- アプリケーションは必要なものだけをキャッシュするため、キャッシュ ヒット率が向上します。
- ローカル キャッシュへのアクセスは、ネットワークの遅延により、データベースへのアクセスよりもおそらく数桁高速になります。たとえ高速なネットワークであってもです。
于 2010-06-03T06:54:56.163 に答える
7
データベース エンジンがデータ、インデックス、またはクエリ結果セットをキャッシュする場合でも、アプリケーションがそのキャッシュを利用するには、データベースへの往復が必要です。
ORM フレームワークは、アプリケーションと同じ空間で実行されます。なので往復はありません。これは単なるメモリ アクセスであり、通常ははるかに高速です。
フレームワークは、必要な限りデータをキャッシュに保持することもできます。データベースは、他の同時クライアントがキャッシュを利用する要求を行ったときに、キャッシュされたデータを予測できない時間に期限切れにすることを決定する場合があります。
アプリケーション側の ORM フレームワークは、データベースが返すことができない形式でデータをキャッシュする場合もあります。たとえば、生データのストリームではなく、Java オブジェクトのコレクションの形式で。データベース キャッシングに依存している場合、ORM はオブジェクトへの変換を繰り返さなければならず、これによりオーバーヘッドが増加し、キャッシュの利点が減少します。
于 2010-06-03T06:59:37.677 に答える
6
また、データベースのキャッシュは、思っているほど実用的ではないかもしれません。これをhttp://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-togetherからコピーしました。これはMySQL 固有のものです。
MySQL にはキャッシュがあるのに、なぜ memcached が必要なのですか?
MySQL キャッシュは、1 つのインスタンスのみに関連付けられています。これにより、キャッシュが 1 つのサーバーの最大アドレスに制限されます。システムが 1 つのサーバーのメモリよりも大きい場合、MySQL キャッシュの使用は機能しません。また、同じオブジェクトが別のインスタンスから読み取られた場合、キャッシュされません。
クエリ キャッシュは書き込み時に無効になります。そのすべてのキャッシュを構築し、誰かがそれに書き込むと消えます。使用パターンによっては、キャッシュがまったくキャッシュにならない場合があります。
クエリ キャッシュは行ベースです。Memcached は、必要なあらゆるタイプのデータをキャッシュでき、データベース行のキャッシュに限定されません。Memcached は、結合なしで直接使用できる複雑で複雑なオブジェクトをキャッシュできます。
于 2010-06-03T07:06:26.337 に答える
6
ここにはたくさんの良い答えがあります。もう 1 点追加します。私は自分のアクセス パターンを知っていますが、データベースは知りません。
私が何をしているかにもよりますが、データが古くなっても、それは実際には問題ではないことを知っています。DB はそうではなく、新しいデータでキャッシュをリロードする必要があります。
しばらくの間、データの一部に何度か戻ってくることを知っているので、それを維持することが重要です。DB はキャッシュに何を保持するかを推測する必要がありますが、私が行っている情報はありません。そのため、DB から何度も取得すると、サーバーがビジー状態の場合、キャッシュにない可能性があります。キャッシュミスが発生する可能性があります。私のキャッシュがあれば、確実にヒットすることができます。これは、単一の行とは対照的に、取得するのが簡単ではないデータ (つまり、いくつかの結合、いくつかのグループ関数) に特に当てはまります。DB にとって、7 の主キーを持つ行を取得するのは簡単ですが、実際の作業を行う必要がある場合、キャッシュ ミスのコストははるかに高くなります。
于 2010-06-05T13:40:28.280 に答える
6
ネットワーク ラウンドトリップに関連するパフォーマンスの考慮事項は正しく指摘されています。
それに加えて、dbms (「データベース」ではない) 以外の場所にデータをキャッシュすると、「最新」であるとまだ提示されている潜在的に古いデータの問題が発生することを追加する必要があります。
パフォーマンス向上の誘惑に屈することは、完全に確実で保証可能な正確で一貫性のあるデータの保証 (完全または少なくともそれに近い) を失うことを犠牲にします。
正確さと一貫性が重要である場合は常に、これを考慮してください。
于 2010-06-03T08:43:12.793 に答える
4
最新のデータベースがキャッシュ機能を提供していることは間違いありませんが、サイトのトラフィックが多く、そのときに多くのデータベーストランザクションを実行する必要がある場合、高いパフォーマンスは得られません。したがって、この場合のパフォーマンスを向上させるには、休止状態のキャッシュが役立ちます。データベースアプリケーションを最適化することによって。キャッシュには、データベースからすでにロードされているデータが実際に格納されるため、アプリケーションがそのデータに再度アクセスするときに、アプリケーションとデータベース間のトラフィックが削減されます。アプリケーションとデータベース間のアクセス時間とトラフィックが削減されます。
于 2010-06-05T13:16:55.870 に答える
3
とはいえ、キャッシュは時々負担になり、実際にサーバーの速度を低下させる可能性があります。高負荷の場合、キャッシュされているものとキャッシュされていないもののアルゴリズムが、入ってくるリクエストに正しく適合しない可能性があります...得られるのは、時間の経過とともにFIFOのように動作し始めるキャッシュです...これは、それ自体が明らかになり始めますキャッシュの背後にあるテーブルに、メモリにキャッシュされるよりもはるかに多くのレコードがある場合...
適切なトレードオフは、キャッシュしたいデータをクラスター化することです。クラスターに更新を送り込むメイン サーバーを用意します。更新を送信/送り出すタイミングは、TTL (存続時間) 設定に応じてテーブルごとに調整できる必要があります。
ユーザーノード上のロジックとデータは、メモリデータベースで開く同じサーバーに配置できます。または、データを取得する必要がある場合は、ネットワーク呼び出しの代わりにパイプを使用するように設定できます...
これは、データをどのように使用するか、およびいつ/場合にクラスター化するかについて考えなければならないものであり、分散トランザクション (複数のデータベースにわたるトランザクション) を認識する必要があります...ただし、キャッシュされているデータが更新される場合他の db スペースへのリンクなしで単独で、これで逃げることができます....
ORM キャッシングの問題は、データベースが別のアプリケーションを介して個別に更新される場合、ORM キャッシュが古くなる可能性があることです...また、セットを更新すると厄介になる可能性があります...更新により、何かが更新される可能性がありますキャッシュにあり、メモリ内で削除/更新する必要があるレコードを特定するための何らかのアルゴリズムが必要です (更新が遅くなります!?) - そして、このアルゴリズムは信じられないほどトリッキーになり、バグが発生しやすくなります!
ORM キャッシングを使用している場合は、単純なルールを守ってください...ほとんど変更されず (ユーザー/ロールの詳細など)、サイズが小さく、リクエストで何度もヒットする単純なオブジェクトをキャッシュします...これ以外の場合次に、パフォーマンスのためにデータをクラスタリングすることをお勧めします。
于 2011-06-08T09:59:40.130 に答える