データベースキャッシュ

データベースキャッシングとは、バックエンドデータベースにアクセスしてオンデマンド（動的）にウェブページを生成するコンピュータアプリケーションの設計に含まれるプロセスです。

これらのアプリケーションが、ブラウザベースのクライアント、Webアプリケーションサーバー、バックエンドデータベースを含むマルチティア環境に展開される場合、^{[ 1 ] [ 2 ]}高いスケーラビリティとパフォーマンスを実現するためにミドルティアデータベースキャッシングが使用されます。^{[ 2 ]}

3層アーキテクチャでは、アプリケーションソフトウェア層とデータストレージ層を異なるホストに配置できます。アプリケーションのスループットはネットワーク速度によって制限される場合があります。この制限は、データベースをアプリケーション層に配置することで最小限に抑えることができます。商用データベースソフトウェアはシステムリソースを大量に消費するため、アプリケーションとデータベースを同じホストに配置することは必ずしも実用的ではありません。このような場合は、より軽量なデータベースアプリケーションを使用して、商用データベース管理システムからデータをキャッシュすることができます。

データベースキャッシングは、クエリワークロードをバックエンドから複数の安価なフロントエンドシステムに分散することでスケーラビリティを向上させます。これにより、データの処理に柔軟性が生まれます。たとえば、プラチナ顧客のデータはキャッシュし、一般顧客のデータはキャッシュしないといったことが可能です。キャッシングは、バックエンドサーバーが利用できない場合でも、キャッシュされたテーブルのみに依存するアプリケーションに継続的なサービスを提供することで、データの可用性を向上させることができます。また、データの局所性によってデータアクセス速度が向上し、ミドルティアとデータティア間の往復を回避することで負荷のピークが平準化されるという利点もあります。^{[ 3 ]}

• 更新可能なキャッシュテーブル：多くのキャッシュシステムは読み取り専用であるため、その使用は非リアルタイムアプリケーションなど、ごく一部のアプリケーションに限られます。
• 双方向更新：更新可能なキャッシュの場合、キャッシュ内で発生した更新はターゲットデータベースに伝播され、ターゲットデータベースで直接発生した更新は自動的にキャッシュに反映される必要があります。
• 同期更新と非同期更新の伝播：キャッシュテーブルの更新は、2つのモードでターゲットデータベースに伝播されます。同期モードでは、データベース操作が完了した後、ターゲットデータベースにも更新が確実に適用されます。非同期モードでは、更新はターゲットデータベースに遅延して反映されます。同期モードは高いキャッシュ一貫性を提供し、リアルタイムアプリケーションに適しています。非同期モードは高いスループットを提供し、ニアリアルタイムアプリケーションに適しています。
• 複数のキャッシュ粒度 - データベースレベル、テーブルレベル、および結果セットのキャッシュ: 企業データベースの大部分は履歴データであり、アクセス頻度は低い。しかし、プレミアム顧客データなど、即座にアクセスする必要がある情報もある。
• キャッシュされたテーブルの復旧：システム障害または停電が発生した場合、キャッシュプラットフォームの再起動中に、キャッシュされたテーブル上のコミット済みトランザクションすべてを復旧する必要があります。
• キャッシュの整合性を検証するためのツール：更新伝播が非同期モードの場合、異なるキャッシュノードとターゲットデータベースのキャッシュが乖離する可能性があります。これは手動で解決する必要があり、不一致を特定し、必要に応じて修正措置を講じる必要があります。
• 水平スケーラビリティ：クラスタコンピューティングは可用性を向上させ、負荷分散を実現します。クラスタ環境におけるキャッシングは複数のノードにまたがり、キャッシュされたデータの一貫性をノード間で維持します。
• キャッシュされていないテーブルへの透過的なアクセスはターゲットデータベースに存在します。データベースキャッシュはクエリを追跡し、アプリケーションコードを変更することなく、データの局所性に基づいてデータベースキャッシュまたは元のデータベースにインテリジェントにルーティングできる必要があります。
• 透過的なフェイルオーバー：キャッシュプラットフォームの障害発生時にも、サービス停止が発生しないようにする必要があります。クライアント接続はターゲットデータベースにルーティングされます。
• アプリケーションへの変更は不要、もしくはごくわずかで済みます。JDBC、ODBCなどの標準インターフェースをサポートすることで、アプリケーションコードの変更なしにシームレスに動作します。また、すべてのストアドプロシージャ呼び出しをターゲットデータベースにルーティングすることで、データベースの移行が不要になります。
• 専用の内部キャッシュを実装する: ScyllaDBなどのパフォーマンス重視のデータベースは、読み取り時にLinuxキャッシュを完全にバイパスし、代わりに行ベースの統合内部キャッシュを使用します。^{[ 4 ]}

• 削除または無効化イベント時のキャッシュウォーキング： RedisやHazelcastなどの外部キャッシュエンジンを利用するキャッシュ設計では、無効化されたオブジェクトに対して削除を発行することで無効化がトリガーされることがよくあります。これにより、1回の書き込み操作で数千件の削除がトリガーされ、パフォーマンスに影響を与える可能性があります。
• キー追跡機能の欠如：外部キャッシュエンジンを使用している場合、リクエストが発生するたびにキャッシュ層でキー検索が頻繁に発生します。検索ミスが発生すると、RTT（ラウンドトリップタイム）が長くなり、リクエスト全体のレイテンシが増加します。しかし、 RedisやHazelcastなどのエンジンはキー変更通知をサポートしており、リモートキャッシュ層でキーが変更された際にローカルキャッシュ層を更新できます。これらのキーをローカルで追跡することで、キャッシュミス時のリモート検索を回避し、キャッシュヒットによるペナルティを防ぐことができます。
• 無効化は時間範囲ではなく、即時イベントとして扱われます。トランザクションの一部としてテーブルが変更される場合、SQL モードによって、別の接続上のクエリが変更を認識できるかどうかが左右されることがあります。そのため、トランザクションがコミットまたはロールバックされるまでは、トランザクション中にテーブルに対して行われた変更は、トランザクションが完了するまでテーブルを揮発性として扱う必要があります。多くの場合、キャッシュ エンジンはクエリの実行前または実行後にのみ結果を無効化します。
• 通信機能のない分散キャッシュ：キャッシュ設計で基盤となるストレージ層を使用している場合、分散キャッシュとして使用される際には、特定の時点で書き込みが行われているテーブルに基づいて、ローカルで無効化が行われます。残念ながら、他のノードが同じテーブルに対してキャッシュオブジェクトを書き込んでいる可能性があり、これらのオブジェクトは無効化されません。アップストリームのクライアント永続化機能を備えたローカルセッションデータに使用する場合は許容範囲内かもしれませんが、セッション間で一貫性を維持する必要のある共有データに使用する場合は、データの一貫性の問題が発生する可能性があります。

• eビジネス向けミドルティアデータベースキャッシング