データベースキャッシング入門

パフォーマンス

簡潔に述べたように、データベースキャッシングは、データのアクセスを容易にすることでデータベースのパフォーマンスを向上させます。キャッシュは、アプリケーションが頻繁に呼び出すデータを参照するための「キーボードショートカット」または「ホットキー」のような役割を果たします。

この高速な要求は、データベースのワークロードを最小限に抑え、繰り返しタスクに非効率な時間を費やすことを防ぎます。代わりに、これらのタスクをより効率的にし、データアクセスを簡素化します。

可用性

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

データベースのパフォーマンスがキャッシング戦略を採用する主な理由であることが一般的ですが、バックエンドの障害が発生した場合に、追加の回復性という利点も得られます。

スケーラビリティ

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

この分散により、プライマリデータベースの負荷が軽減され、コスト削減とデータ処理の柔軟性向上が期待できます。この結果、スケールアップの必要性が緩和され、既存のリソースでより多くのことが可能になり、スケールアップの必要性を将来に先送りできる可能性があります。

キャッシュアサイド

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

キャッシュアサイド設計は、汎用的なキャッシング戦略として優れています。この戦略は、読み込み負荷が高いアプリケーションに特に役立ちます。これにより、頻繁に読み込まれるデータが、多くの受信読み込み要求にすぐに対応できるよう手元に保持されます。キャッシュがデータベースから分離されていることには、さらに2つの利点があります。キャッシュ障害が発生した場合でも、キャッシュデータに依存するシステムは直接データベースにアクセスできます。これにより、ある程度の回復性が提供されます。次に、キャッシュが分離されているため、データベースとは異なるデータモデルを使用できます。

一方、キャッシュアサイド戦略の主な欠点は、データベースとの一貫性の問題が発生する可能性があることです。一般的に、書き込まれるデータは直接データベースに送られます。そのため、キャッシュとプライマリデータベースとの間に一時的な不整合が生じる可能性があります。ニーズに応じて、これを解消するための異なるキャッシュ戦略があります。

リードスルー

リードスルーキャッシュ方式では、キャッシュはアプリケーションとデータベースの間に配置されます。アプリケーションからデータベースへの一直線上にキャッシュが中央にあると想像できます。この戦略では、アプリケーションは読み込みのために常にキャッシュと通信し、キャッシュヒットが発生すると、データは即座に返されます。キャッシュミスの場合、キャッシュはデータベースから不足しているデータを取得し、それをアプリケーションに返します。データの書き込みについては、アプリケーションは引き続きデータベースに直接アクセスします。

リードスルーキャッシュも読み込み負荷の高いワークロードに適しています。リードスルーとキャッシュアサイドの主な違いは、キャッシュアサイド戦略ではアプリケーションがデータの取得とキャッシュへの格納を担当するのに対し、リードスルー設定では、そのロジックがライブラリや別のキャッシュプロバイダーによって行われる点です。リードスルー設定は、キャッシュとデータベース間のデータ不整合の可能性に関して、キャッシュアサイドと似ています。

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

ライトスルー

ライトスルーキャッシング戦略は、これまでに述べた2つの戦略とは異なり、データをデータベースに書き込むのではなく、まずキャッシュに書き込み、キャッシュがすぐにデータベースに書き込みます。この配置は、リードスルー戦略と同様に、アプリケーションが中央にある一直線として視覚化できます。

ライトスルー戦略の利点は、キャッシュが確実に書き込まれたデータを持つため、キャッシュがメインデータベースからデータを要求する際に、新しい読み込みで遅延が発生しないことです。この構成のみを使用する場合、アクションがキャッシュとデータベースの両方に行かなければならないため、書き込みレイテンシが余分にかかるという大きな欠点があります。これはすぐに発生するはずですが、依然として2つの書き込みが連続して発生します。

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

ライトバック

ライトバックは、ライトスルー戦略とほぼ同じように機能しますが、1つの重要な点が異なります。ライトバック戦略では、アプリケーションは再びキャッシュに直接書き込みます。しかし、キャッシュはすぐにデータベースに書き込まず、遅延してから書き込みます。

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

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

ライトアラウンド

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

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