ファイブ戦略はキャッシュ解析の組み合わせを使用するプロセスの長所と短所をまとめます

今日のキャッシュ戦略上の記事の翻訳、元のタイトルがCacheing戦略で、どのように良い要約を感じ、見て右のひとつ、友人を選択するには、私の友人の多くの観点から英語を読むのが面倒なので、壊れたレベルでそれピッピ大丈夫感じる方法を、波を翻訳しようと、我々はより多くの人が見て得るのを助けることを楽しみにすることができます。

キャッシュは、システムのパフォーマンスを改善する最も簡単な方法の一つです。これとは対照的に、データベース（またはのNoSQLデータベース）の速度が比較的遅いですが、速度は、多くの場合、勝利への鍵です。

適切に使用した場合、キャッシュは、応答時間を短縮し、コストデータベースの負荷を軽減することができます。これは非常に異なるものになります右のいずれかを選択するいくつかのキャッシング戦略のリストです。キャッシュポリシーは、データとデータアクセスパターンに依存します。言い換えれば、どのようにデータが読み書きされます。例えば：

システムは、追記多くを読ん少ないんでしょうか？（例えば、時間ベースのログ）
データは一度だけ書かれ、何回も読まれるかどうか？（このようなユーザプロファイルなど）
データが返されるだけやるいつものですか？（例えば、検索クエリ）

右のキャッシュ戦略を選択すると、パフォーマンスを向上させるための鍵です。のは、さまざまなキャッシュ戦略を簡単に見てみましょう。

最初：キャッシュ - 別として

これはおそらく、キャッシングのための最も一般的に用いられている方法です。キャッシュが配置されている間、アプリケーションはキャッシュとデータベースに直接話しています。

簡単に説明します。

アプリケーションが最初にキャッシュをチェック。
キャッシュ内で見つかった場合、彼はそれがバッファをヒットしていると述べました。データが読み込まれ、アプリケーションに返されます。
キャッシュ内に見つからない場合は、キャッシュがミス。それ以降は、同じデータを読み込むことをデータ・キャッシュ・ヒットに格納できるようにするアプリケーションは、いくつかの余分な作業を行う必要があり、それがデータを読み込むためのデータベースを照会する必要があり、データは、キャッシュにも、クライアントに返す、とされます。

キャッシュ・脇には、より多くのシナリオを読み、特に適切です。キャッシュアサイドキャッシュ無効化システムを使用すると、一定の弾性を有しています。キャッシュ・クラスタがダウンしている場合、システムがまだデータベースに直接アクセスして操作することができます。（応答時間が非常に悪くなることが多くの助けではないピーク負荷、中にキャッシュ秋場合。しかし、最悪の場合は、データベースが動作を停止するかもしれないということです。）

もう一つの利点は、データモデルは、データベースモデルのキャッシュデータと異なる可能性があることです。例えば、生成された複数のクエリに応答して、リクエストIDに格納することができます。

場合は、キャッシュはさておき、最も一般的な戦略は、データベースへのデータの書き込みに直接書き込むことです。これが発生すると、キャッシュがデータベースと一致しないことがあります。この問題を解決するため、開発者は多くの場合、導入TTL、TTLと有効期限が切れるまで古いデータを提供し続けること。データの鮮度を確保する必要がある場合、開発者は、キャッシュエントリが無効であることを確認、または適切なライトストラテジを使用するか、我々は後で説明します。

第二：読み取りけれどもキャッシュ

一貫した読み取りけれども戦略の下でキャッシュデータベース。キャッシュミスが、それはデータベースから適切なデータをロードし、キャッシュフィル・アプリケーションに返す場合（図を参照）。

脇キャッシュとリードスルー戦略は、データが最初の読み取りにロードされた場合にのみ、すなわち、ロードデータの遅延です。

リードスルーとキャッシュアサイドは非常に似ていますが、少なくとも二つの重要な違いがありますが。

キャッシュアサイドでは、アプリケーションがデータベースからデータを取得し、キャッシュに移入する責任があります。リードスルーでは、このロジックは、一般的に、ライブラリのサポートや、独立したキャッシュによって提供されます。
キャッシュさておき、異なるデータモデルがリードスルーキャッシュでは、データベースモデルのデータとは異なるではありません。

同じデータを複数の要求は、リードスルーキャッシュは、ワークロードの大規模な量を読み取るために最適であるとき。たとえば、ニュース記事。欠点は、最初の要求データが、それは常にキャッシュミスにつながり、リードキャッシュのコストに追加データをロードする際に、ということです。開発者は、手動でこの問題に対処するために、「温かい」や「暖かい」キャッシュにクエリを発行します。キャッシュ脇のように、データがキャッシュとデータベース間の一貫性のないなる可能性があり、ライトストラテジでのソリューションは、我々は次でこれを確認できます。

第三：ライトスルーキャッシュ

このライトストラテジでは、データはまずキャッシュに書き込まれ、その後、データベースに書き込まれました。キャッシュとデータベースの一貫性は、常にメインデータベースにキャッシュライトスルー。

その一部については、ライトスルーキャッシュは、データがキャッシュに書き込まれ、その後、プライマリ・データベースに書き込まれているので、実際に、彼らは、追加の書き込みレイテンシを導入し、役割の多くを思えません。我々はキャッシュ無効化技術を使用する必要がないように、リードスルーと併せて使用する場合しかし、我々はリードスルーのすべての利点を取得し、また、保証データの一貫性を受け取りました。

DynamoDBのアクセラレータ（DAX）は、ライトスルー/リードスルーキャッシュがあるの良い例です。これは、DynamoDBのアプリケーションでインライン化。DynamoDBの読み書きは、DAXによって達成することができます。（注：DAXを使用する予定がある場合は、そのデータの一貫性モデルとどのようにそれがDynamoDBのと相互作用を理解してください。）

第四の書き込みアラウンド

この戦略の下では、直接データベースにデータは、データのみをキャッシュに読み込むことができます。、読み取りまたは決して良いパフォーマンスを提供するために、あまり頻繁に読まケースの周りを読み書きスルーと組み合わせることができ、一度だけデータを書き込みます。例えば、リアルタイムのログメッセージやチャットルーム。また、このモードでは、キャッシュ・脇と組み合わせて使用することができます。

第五ライトバック

この戦略の下で、アプリケーションがキャッシュにデータを書き込み、キャッシュはすぐに確認され、時間遅延データの後にデータベースに書き込まれます。時には、この戦略はまた、ライトビハインドとして知られています。

ライトバックキャッシュは、ライトヘビーワークロードワークロードのために非常に有益な書き込みパフォーマンスを改善します。リードスルーと組み合わせて、そしてそれは混合ワークロードのために非常に有効である場合には、最近更新され、アクセスデータがキャッシュ内に常に利用可能です。これは、大幅にデータベースの障害の弾力性を持っており、データベースのいくつかのダウンタイムを許容することができます。バッチまたはマージをサポートしている場合、それは負荷を軽減し、コストを削減しますた、全体的なデータベースの書き込み操作を減らすことができます。

一部の開発者は、キャッシュさておき使用しながら、Redisのを使用し、よりよいピーク負荷のピーク期間を吸収するために2つの戦略のライトバック。主な欠点は、キャッシュミスならば、データは永久に失われる可能性があり、ということです。ほとんどの内部リレーショナルデータベースストレージエンジンは（InnoDBのような）デフォルトのライトバックキャッシュが有効になっています。クエリメモリは最初に書かれ、そして最終的にディスクにフラッシュされます。

概要

この記事では、異なるキャッシュ戦略の長所と短所を議論します。実際には、慎重に、あなたの目標を評価するデータアクセス（リード/ライト）モードを、理解し、政策の最善の政策や組み合わせを選択してください。

あなたがする方法を間違って選択した場合は？あなたは追加の遅延を導入することができる？あなたの目標やアクセスパターンと一致していない、あるいは少なくともすべての利点が表示されません。ライトスルー/リードスルーが実際の書き込みアラウンド/リードスルー（低周波アクセスデータが書き込まれている）で使用されるべきである場合、例えば、キャッシュは、ごみの存在下または非存在下で使用されます。キャッシュが十分に大きい場合、それは問題ではないかもしれない、と言うことができます。しかし、メモリがない十分に大きいと、常にサーバーのコストを考慮する必要がある多くの実用的な高スループットシステムにおいて、正しい戦略は非常に重要です。