How to choose between cache-aside, read-through, write-through, client-side, and distributed caching strategies 最近述べたように、 post, we are delighted that Pekka Enberg decided to write 3章をスポンサーすることを誇りに思います。 なぜデータをキャッシュするのか。 ラテンシスについての本一覧 Get the Latency book excerpt PDF Get the Latency book excerpt PDF Get the Latency book excerpt PDF また、Pekkaは、その本の主要な取り出しを1つにシェアしました。 (現在、ご要望によりご利用いただけます)。 タイトル:Building Low Latency Apps わたしたちの継続を 本書は、Pekkaのキャッシュ・カプセルからより多くのエントリを含み、出版者の許可を得てここで再印刷されています。 ラテン ♪♪♪ アプリケーションにキャッシュを追加する場合、まずキャッシュ戦略を考慮する必要があります、これはキャッシュやベースのバックアップストア(データベースやサービスなど)から読み書きがどのように起こるかを決定します。 言い換えれば、あなたのアプリケーションがキャッシュから値を見つけるが、値はそこにないか、または有効期限が切れた場合、キャッシュ戦略は、あなたのアプリケーションであるか、バックアップストアから値を取得するキャッシュであるかを命令します。 Cache-aside キャッシュ キャッシュサイドキャッシングは、おそらくあなたが遭遇する最も典型的なキャッシング戦略です。キャッシュヒットが発生したとき、データアクセスの遅延は通信の遅延によって支配され、通常は小さいので、キャッシュサーバやアプリケーションのメモリスペースに近くにキャッシュを得ることができます。 ただし、キャッシュが欠けている場合、キャッシュサイドキャッシュで、キャッシュはアプリケーションによって更新されるパシブストアです. That is, the cache just reports a miss and the application is responsible for picking data from the backing store and updating the cache. 図1は、アクションにおけるキャッシュサイドキャッシュの例を示しています. An application looks up a value from a cache by a caching key, which determines the data the application is interested in. アプリケーションは、キャッシュキーによってキャッシュから値を調べ、アプリケーションが興味を持っているデータを決定します。 キーがキャッシュに存在する場合、キャッシュは、アプリケーションが使用できるキーに関連付けられた値を返します。しかし、キーが存在しないか、またはキャッシュ内で有効期限が切れた場合は、アプリケーションが処理しなければならないキャッシュミスがあります。 たとえば、ユーザー情報をキャッシュし、ユーザー ID を検索キーとして使用しているとします。その場合、アプリケーションはユーザー ID によってクエリを実行して、データベースからユーザー情報を読み取ります。データベースから返されたユーザー情報は、キャッシュに保存できる形式に変換されます。その後、キャッシュはユーザー ID をキャッシュキーと値として更新します。例えば、このタイプのキャッシュを実行する典型的な方法は、データベースから返されたユーザー情報を JSON に変換し、キャッシュに保存することです。 キャッシュサイドキャッシングは、Redisのようなキャッシュサーバを簡単に設定し、データベースクエリとサービス応答をキャッシュするために使用するので人気があります。キャッシュサイドキャッシングでは、キャッシュサーバは被動的で、どのデータベースを使用するか、結果がキャッシュにどのようにマッピングされているかを知る必要はありません。 多くの場合、キャッシュサイドキャッシングは、アプリケーションの遅延を減らす簡単かつ効果的な方法です. あなたはあなたのアプリケーションの近くのキャッシュサーバーに最も関連する情報を有することによって、データベースアクセスの遅延を隠すことができます。 ただし、キャッシュサイドキャッシングは、データの一貫性または新鮮性の要件がある場合にも問題になる可能性があります. たとえば、キャッシュ内のキーを検索している複数の同時読者がある場合は、アプリケーションで同時にキャッシュの欠落を処理する方法を調整する必要があります。 しかし、キャッシュサイドキャッシングでは、キャッシュとデータベースが互いに知らないため、トランザクションサポートを失うことがあり、アプリケーションがデータの更新を調整する責任があります。最後に、キャッシュサイドキャッシングは、いくつかのキャッシュ検索がキャッシュミスでデータベースの読み込み遅延を経験するため、重要な尾遅延を有する可能性があります。それは、キャッシュヒットの場合でも、アクセス遅延は近隣のキャッシュサーバーから来ているため、迅速です。 Read-Through キャッシュ Read-through caching is a strategy where, unlike cache-side caching, the cache is an active component when there is a cache miss. When there is a cache miss, a read-through cache attempts to read a value for the key from the backing store automatically. Latency is similar to cache-side caching, although backing store retrieval latency is from the cache to the backing store, not from application to backing store, which may be smaller, depending on your deployment architecture. キャッシュは、キャッシュ・ミスがあるときにアクティブなコンポーネントです。 図2は、アクション中の読み込みキャッシュの例を示します。アプリケーションはキーにキャッシュ検索を実行し、キャッシュが欠けている場合、キャッシュはデータベースに読み取りを行い、キーの値を取得します。キャッシュはそれから自らを更新し、アプリケーションに値を返します。 バックアップキャッシュは、バックアップストアの結果をキャッシュに保存するために、クエリの結果を JSON または類似の形式に変換する必要がありますが、例えば、バックアップストアが SQL データベースサーバーである場合は、クエリの結果をキャッシュに保存するために、クエリの結果を JSON または類似の形式に変換する必要があります。 しかし、キャッシュは更新を調整し、データベースは読み込みキャッシュで読むので、アプリケーションにトランザクションの保証を提供し、同時キャッシュの欠落に一貫性を確保できます。 もちろん、尾の遅延の同じ警告は、キャッシュサイドキャッシュに適用されますが、例外として、アクティブなコンポーネントとして、キャッシュサイドキャッシュは、例えば、リフレッシュ前キャッシュで遅延をよりよく隠すことができます。 Caching を通じて書く Cache-side and read-through caching are strategies around caching reads, but sometimes, you also want the cache to support writes. In such cases, the cache provides an interface for updating the value of a key that the application can invoke. In the case of cache-side caching, the application is the only one communicating with the backing store and, therefore, updates the cache. However, with read-through caching, there are two options for dealing with writes: write-through and write-behind caching. Cache-side and read-through caching are strategies around caching reads, but sometimes, you also want the cache to support writes. こうした場合、キャッシュは、キーの値を更新するためのインターフェイスを提供します。 書き込みキャッシュは、キャッシュへの更新がバックアップストアに直ちに広がる戦略です。キャッシュが更新されるたびに、キャッシュはキャッシュされた値でバックアップストアを同期的に更新します。書き込みキャッシュの書き込み遅延は、バックアップストアへの書き込み遅延によって支配されますが、これは重要です。 図3に示すように、アプリケーションはキャッシュが提供するインターフェイスを用いてキャッシュを更新します。キャッシュは新しい値でその状態を更新し、新しい値でデータベースを更新し、アプリケーションにキャッシュの更新を承認するまで、データベースが更新を委ねるのを待っています。 ただし、非トランザクションのキャッシュでは、キャッシュとバックアップストアはエラーが存在する場合に同期されない場合があります。例えば、キャッシュに書き込むことが成功した場合、バックアップストアに書き込むことが失敗した場合、両方が同期されなくなります。もちろん、キャッシュとデータベースの両方が更新されているか、どちらもないことを保証するために、いくつかの遅延を取引することによって、キャッシュとバックアップストアが取引の保証を提供することができます。 読み込みキャッシュと同様に、書き込みキャッシュは、キャッシュがデータベースに接続してキャッシュ値をデータベースクエリに変換できることを前提とします。 たとえば、ユーザー ID がキーとして機能し、JSON ドキュメントが値を表すユーザーデータをキャッシュしている場合、キャッシュはユーザー情報の JSON 表示をデータベースの更新に変換できる必要があります。 write-through caching では、最も簡単なソリューションは、しばしばデータベースに JSON を格納することです。 write-through caching の主な欠点は、基本的にデータベースの commit 遅延に等しいキャッシュ アップデートに関連する遅延です。 後ろに書くCaching Write-behind caching strategy は、データベースの更新を防ぐ書き込みキャッシングとは異なり、すぐにキャッシングを更新します. In other words, with write-behind caching, the cache may accept multiple updates before updating the backing store, as shown in Figure 4, where the cache accepts three cache updates before updating the database. バックアップストアが非同期的に更新されるため、書き込み後のキャッシュの書き込み遅延は、書き込み後のキャッシュよりも低いため、キャッシュはアプリケーションにすぐに書き込みを認識し、低遅延の書き込みにつながり、その後バックアップストアの更新を実行します。しかし、書き込み後のキャッシュの欠点は、キャッシュがキャッシュとデータベースが同期していることをもはや保証できないため、トランザクションのサポートを失うことです。 クライアントサイドキャッシュ クライアント側のキャッシュ戦略とは、アプリケーション内のクライアント層にキャッシュがあることを意味します。Redisのようなキャッシュサーバーは、メモリ内キャッシュを使用しますが、アプリケーションは、Redisプロトコルを介してキャッシュにアクセスするためにネットワークを介して通信する必要があります。 アプリケーションがデータセンターで実行されているサービスである場合、キャッシュサーバーはキャッシュに最適であるため、データセンター内のネットワークツアーは迅速であり、キャッシュの複雑さはキャッシュ自体にあります。 クライアント側のキャッシュでは、読み込みと書き込みのキャッシュの組み合わせは、読み込みと書き込みの両方が高速であるため、遅延の観点から最適です。もちろん、クライアントは通常、データベースに直接接続することはできませんが、代わりにプロキシまたはAPIサーバーを通じて間接的にデータベースにアクセスします。 低遅延クライアントサイドキャッシュを必要とする多くのアプリケーションでは、レプリケーションに対するローカルファーストアプローチはより実用的である可能性がありますが、簡単な読み取りキャッシュの場合、クライアントサイドキャッシュは低遅延を達成するための良いソリューションです。 分散キャッシュ たとえば、アプリケーション内のキャッシュまたは単一の Redis サーバーを使用して、PostgreSQL データベースからクエリをキャッシュします。 このような分散キャッシュでは、独立してまたはキャッシュクラスターで動作するキャッシュのいくつかのインスタンスがあります。分散キャッシュでは、レプリケーションについての第4章と分割についての第5章で議論された同様の複雑さと考慮点が多くあります。分散キャッシュでは、すべてのキャッシュデータを各インスタンスに適合するのではなく、ノード間で分割されたキャッシュデータがあります。同様に、高可用性と低いアクセス遅延のために複数のインスタンスでパーティションを複製できます。 全体として、分散キャッシングはキャッシング、パーティション、複製の利点と問題の交差点であるため、それに従っている場合は注意してください。 ♪♪♪ 読み続けるためには、 ScyllaDBまたは . Download the 3-chapter Latency excerpt 無料 Manningの本を購入する Cynthia Dunlopについて Cynthia は ScyllaDB のコンテンツ戦略のシニアディレクターであり、20年以上にわたりソフトウェア開発と品質エンジニアリングについて書いています。
