どのソースからでもデータをリクエストする場合、常に多少の遅延が発生します。 Web サーバーへの ping はミリ秒単位で測定され、ストレージ アクセス時間はマイクロ秒単位で遅延が発生する可能性がありますが、RAM 遅延は CPU クロック サイクルで測定されます。 もちろん、この種の速度はほんの数十年前には考えられなかったでしょうが、現在では決して十分な速さではありません。 アクセス速度は、通常、何らかの形でパフォーマンスのボトルネックになります。 これに対処できる方法の 1 つは、キャッシュを使用することです。
キャッシングとは、リソースの一時的なコピーを、通常よりも高速にアクセスできるように保存するプロセスです。 ソフトウェアとハードウェアの両方で、膨大な範囲の実装があります。 キャッシュは、読み取りキャッシュ、書き込みキャッシュ、またはその両方として機能できます。
読み取りキャッシュ
読み取りキャッシュでは、以前に要求されたデータがキャッシュに格納され、アクセスが高速化されます。 一部のシナリオでは、キャッシュにデータをプリエンプティブにロードして、後続のリクエストだけでなく、最初のリクエストをキャッシュから提供することもできます。
最もよく知られている読み取りキャッシュは、ブラウザーのキャッシュです。 ここで、ブラウザーは要求されたリソースのローカル コピーを保存します。 これは、Web ページが再ロードされた場合、または同じコンテンツの多くを使用する同様のページがロードされた場合に、そのコンテンツを Web サーバーではなくキャッシュから提供できることを意味します。 これは、Web ページの読み込みが速くなるだけでなく、Web の負荷も軽減されます。 サーバーとユーザーがダウンロードする必要があるデータの量を減らします。これは従量制で重要になる可能性があります 接続。
RAM 自体も、ハード ドライブ内のデータの読み取りキャッシュとして機能します。 この場合、実行中のプログラムのデータは先制的に RAM にロードされるため、CPU はより高速にアクセスできます。 RAM からのデータはさらに CPU キャッシュにキャッシュされますが、CPU キャッシュはギガバイトではなくメガバイト単位で測定されるため、このプロセスはより複雑になります。
書き込みキャッシュ
書き込みキャッシュは、低速のデバイスに書き込まれるデータを吸収できるキャッシュです。 この一般的な例は、最新の SSD の SLC キャッシュです。 このキャッシュでは、データをこれ以上高速に読み取ることはできません。 ただし、SSD の残りの部分を構成する TLC または QLC フラッシュに書き込むよりも、書き込みの方がはるかに高速です。 SLC キャッシュは高速書き込み操作を吸収し、そのデータをできるだけ早く TLC フラッシュにオフロードします。TLC フラッシュは、はるかに優れたストレージ密度を提供しますが、書き込み速度も大幅に低下します。 このようにフラッシュ メモリを使用すると、高速な書き込み速度と高い記憶密度の両方を実現するためにフラッシュ メモリが最適化されます。
ハイブリッド キャッシュ
読み取りキャッシュと書き込みキャッシュの両方として機能できるキャッシュを処理する方法は多数あります。 これらの方法はそれぞれ、異なる方法で書き込み操作を処理し、利点と欠点があります。 3 つのオプションは、ライトアラウンド、ライトスルー、およびライトバックです。 ライトアラウンド キャッシュは書き込み時にキャッシュを完全にスキップします。ライトスルー キャッシュはキャッシュに書き込みますが、ストレージに書き込まれたときにのみ操作が完了したと見なします。 ライトバック キャッシュはキャッシュに書き込み、操作が完了したと見なし、必要に応じてキャッシュをストレージに転送します。
ライトアラウンドは、キャッシュ チャーンを最小限に抑えるため、大量の書き込みが予想される場合に役立ちます。 ただし、書き込まれたデータのいずれかを読み取る操作は、最初に少なくとも 1 つのキャッシュ ミスに直面することを意味します。 ライトスルー キャッシュは、書き込み操作をすぐにキャッシュします。つまり、最初に要求されたときにキャッシュから結果を提供できます。 ただし、完了したと見なされるには、書き込み操作でデータをディスクにも書き込む必要があり、これによりレイテンシが追加されます。 ライトバック キャッシュにはライトスルーと同じ利点があり、書き込まれたデータをキャッシュからすぐに提供できます。 ただし、ディスクへの書き込み操作が完了したと見なされる必要はありません。 これにより、書き込みレイテンシが短縮されますが、キャッシュが揮発性であり、電源が失われる前にデータをストレージに書き戻せない場合、データ損失のリスクが伴います。
キャッシュからデータを削除するには?
キャッシュの制限要因の 1 つは容量です。 キャッシュが大きいと検索に時間がかかり、そもそもキャッシュを使用する利点のかなりの部分が失われます。 また、キャッシュに使用されるメモリ テクノロジは、キャッシュ元のメモリよりも高価になる傾向があります。 そうでない場合は、そのメモリ層がパフォーマンスを向上させるためにメモリ テクノロジを切り替えた可能性があります。 これらの要因はどちらも、特にキャッシュ元のストレージ メディアと比較した場合、キャッシュが比較的小さい傾向があることを意味します。 RAM はストレージよりも容量が少なく、CPU キャッシュは RAM よりも容量が少なくなります。 SLC キャッシュは、TLC メモリよりも容量が少なくなります。
これはすべて、キャッシュする必要がある新しいデータ用にスペースを解放するために、キャッシュからデータを循環させることがしばしば必要であることを意味します。 これにはさまざまなアプローチがあります。 「使用頻度が最も低い」は、アクセス数が最も少ないキャッシュ エントリを削除することを優先します。 これは、将来のキャッシュ ミスへの影響が最も少ないエントリを予測するのに役立ちますが、 最近追加されたエントリもアクセス数が少ないものとしてカウントされ、キャッシュにつながる可能性があります チャーン。
「最近使用されていない」は、しばらく使用されていないキャッシュ エントリを削除することを好みます。 これは、それらが現在使用されていないことを前提としていますが、しばらく前に頻繁に使用されていたかどうかは考慮されていません. 「最近使用したもの」は、最近使用されたキャッシュ エントリを削除することを好みます。 最良のアプローチは、一般に、使用状況の統計情報に基づいて、3 つすべてを組み合わせることです。
古い情報とセキュリティ リスク
キャッシュの主なリスクは、そこに含まれる情報が古くなる可能性があることです。 元のデータが更新され、キャッシュ エントリが古くなった場合、キャッシュ エントリは古くなったと見なされます。 提供されているライブ コピーがキャッシュされたコピーと一致していることを定期的に確認することが重要です。
特に Web サイトでは、キャッシュできるデータとできないデータを識別することも非常に重要です。 たとえば、変更されていない大きな JavaScript ファイルがキャッシュされてもまったく問題ありません。 これにより、ユーザーは毎回ダウンロードする必要がなくなり、同じキャッシュによって提供される他のユーザーにとってもメリットがあります。 ただし、セッション固有のデータをキャッシュすることはできません。 自分自身としてサインインしているときにメッセージング アプリを閲覧したときに、別のユーザーのメッセージのキャッシュ バージョンが表示された場合にどうなるか想像してみてください。 ありがたいことに、Web サーバーはキャッシュできるリソースとできないリソースを指定できます。これらの問題は一般的によく知られているため、このような問題はほとんどありません。
結論
キャッシュとは、最近使用したデータを、通常のデータ アクセス プロセスを再度完了するよりも高速にアクセスできるストレージ メソッドに格納できるメモリの一部です。 通常、キャッシュは容量が制限されているため、キャッシュがいっぱいになるとエントリを削除する必要があります。 キャッシュは通常、ユーザーに対して透過的です。つまり、結果がキャッシュ経由で提供されたことを示す唯一の指標はレイテンシーです。