データベースキャッシュ入門

パフォーマンス

前述のように、データベースキャッシュは、データへのアクセスを容易にすることで、データベースのパフォーマンスを向上させます。キャッシュは、アプリケーションが頻繁に呼び出しているデータを参照するための、一種の「キーボードショートカット」または「ホットキー」として機能します。

この高速なリクエストにより、データベースのワークロードを最小限に抑え、反復的なタスクに非効率な時間を費やすのを防ぐことができます。代わりに、これらのタスクをより効率的にし、データアクセスを簡素化します。

可用性

100％フェイルオーバー戦略ではありませんが、キャッシュはデータベース全体の可用性にもメリットをもたらします。キャッシュの保存場所によっては、プライマリデータベースサーバーが何らかの理由で利用できなくなった場合に、アプリケーションがデータを呼び出す場所をキャッシュが提供できます。

データベースのパフォーマンスは、一般的にキャッシュ戦略を採用する主な理由ですが、バックエンドで障害が発生した場合の追加の復元力という追加のメリットもあります。

スケーラビリティ

追加された高可用性と同様に、データベースキャッシュはスケーラビリティにプラスの効果をもたらします。データベースのスケーリング戦略の主な考慮事項にすべきではありませんが、データベースのパフォーマンスを向上させるためにキャッシュを実装すると、データベースのワークロードが軽減され、バックエンドクエリがエンティティ全体に分散されます。

この分散により、プライマリデータベースの負荷が軽減され、コストが削減され、データ処理の柔軟性が向上します。この結果、スケーリングの必要性が軽減され、手元にあるリソースをより有効活用でき、スケーリングの必要性を将来に先送りできる可能性があります。

キャッシュアサイド

キャッシュアサイド構成では、データベースキャッシュはデータベースの隣に配置されます。アプリケーションがデータをリクエストすると、最初にキャッシュをチェックします。キャッシュにデータがある場合（キャッシュヒット）、それが返されます。キャッシュにデータがない場合（キャッシュミス）、アプリケーションはデータベースにクエリを実行します。次に、アプリケーションはそのデータを後続のクエリのためにキャッシュに保存します。

キャッシュアサイド設計は、一般的な目的のキャッシュ戦略として適しています。この戦略は、読み取り負荷の高いワークロードを持つアプリケーションに特に役立ちます。これにより、頻繁に読み取られるデータが、多くの受信読み取りリクエストのために手元に置かれます。キャッシュがデータベースから分離されていることから、さらに2つの利点があります。キャッシュ障害が発生した場合でも、キャッシュデータに依存するシステムはデータベースに直接アクセスできます。これにより、ある程度の復元力が得られます。第二に、キャッシュを分離することで、データベースのデータモデルとは異なるデータモデルを採用できます。

一方、キャッシュアサイド戦略の主な欠点は、データベースからの不整合が発生する可能性が開かれていることです。一般的に、書き込まれるデータはデータベースに直接送信されます。したがって、キャッシュはプライマリデータベースとの間で不整合期間が発生する可能性があります。ニーズに応じて、これに対抗するためのさまざまなキャッシュ戦略があります。

リードスルー

リードスルーキャッシュ構成では、キャッシュはアプリケーションとデータベースの間に配置されます。アプリケーションからデータベースへの直線の中央にキャッシュがあるように視覚化できます。この戦略では、アプリケーションは常に読み取りのためにキャッシュと通信し、キャッシュヒットが発生すると、データがすぐに返されます。キャッシュミスの場合、キャッシュはデータベースから不足しているデータを入力し、それをアプリケーションに返します。データ書き込みの場合、アプリケーションは引き続きデータベースに直接アクセスします。

リードスルーキャッシュも、読み取り負荷の高いワークロードに適しています。リードスルーとキャッシュアサイドの主な違いは、キャッシュアサイド戦略では、アプリケーションがデータをフェッチしてキャッシュをpopulateする責任があるのに対し、リードスルーセットアップでは、ロジックはライブラリまたは何らかの個別のキャッシュプロバイダーによって行われることです。リードスルーセットアップは、キャッシュとデータベース間の潜在的なデータ不整合に関して、キャッシュアサイドと似ています。

リードスルーキャッシュ戦略には、新しい読み取りリクエストが来るたびにデータ​​を取得するためにデータベースにアクセスする必要があるという欠点もあります。このデータは以前にキャッシュされたことがないため、データをロードする必要があります。開発者が手動で発生する可能性の高いクエリを発行することにより、キャッシュを「ウォーミング」してこの遅延を軽減するのが一般的です。

ライトスルー

ライトスルーキャッシュ戦略は、データ​​ベースにデータを書き込む代わりに、最初にキャッシュに書き込み、キャッシュがすぐにデータベースに書き込むため、前述の2つとは異なります。構成は、リードスルー戦略と同様に、アプリケーションが中央にある直線として視覚化できます。

ライトスルー戦略の利点は、キャッシュに書き込まれたデータが確実にあることと、キャッシュがメインデータベースからリクエストしている間、新しい読み取りで遅延が発生しないことです。この構成のみを行う場合、アクションはキャッシュに移動してからデータベースに移動する必要があるため、書き込みレイテンシが追加されるという大きなデメリットがあります。これはすぐに発生する必要がありますが、それでも連続して2回の書き込みが発生します。

真のメリットは、ライトスルーをリードスルーキャッシュと組み合わせることで得られます。この戦略は、リードスルーキャッシュ戦略の前述のすべての利点と、データ不整合の可能性を排除するという追加の利点を採用します。

ライトバック

ライトバックは、1つの重要な詳細を除いて、ライトスルー戦略とほぼ完全に同じように機能します。ライトバック戦略では、アプリケーションは再びキャッシュに直接書き込みます。ただし、キャッシュはすぐにデータベースに書き込むのではなく、遅延後に書き込みます。

データベースへの書き込みをすぐに行うのではなく、遅延させることで、書き込み負荷の高いワークロードでのキャッシュへの負担が軽減されます。これにより、ライトバック、リードスルーの組み合わせは、混合ワークロードに適しています。この組み合わせにより、最新の書き込みデータとアクセスされたデータが常に存在し、キャッシュを介してアクセスできるようになります。

キャッシュからデータベースへの書き込みを遅延させることで、全体的な書き込みパフォーマンスが向上し、バッチ処理がサポートされている場合は、全体的な書き込みも削減されます。これにより、コスト削減と全体的なワークロード削減の可能性が開かれます。ただし、キャッシュ障害が発生した場合、この遅延により、データベースへのバッチまたは遅延書き込みがまだ発生していない場合に、データが失われる可能性が開かれます。

ライトアラウンド

ライトアラウンドキャッシュ戦略は、キャッシュアサイドまたはリードスルーのいずれかと組み合わされます。この構成では、データは常にデータベースに書き込まれ、読み取られるデータはキャッシュに移動します。キャッシュミスが発生した場合、アプリケーションはデータベースを読み取り、次回のためにキャッシュを更新します。

この特定の戦略は、データが一度だけ書き込まれ、更新されないインスタンスで最もパフォーマンスが高くなります。データは非常にまれにしか、またはまったく読み取られません。