MakingSenseofStreamProcessing
Materialized Views: Self-Updating Caches †
要約 †
- マテリアライズド・ビューは、自分でキャッシュをアップデートしてくれる。
- 事前に計算されキャッシュミスもそれによるデータベースに対するロードも存在しない。
- ビュー内の読込み最適化表現に変換する明確な変換プロセスがある。
- 典型的なリード・スルー・キャッシュ・アプローチでは、対照的にキャッシュ管理ロジックはアプリケーションの他の部分と深く織り交ぜられているため、バグが発生しやすくなり、根拠がわかりづらい。
詳細 †
- マテリアライズド・ビューのアイデアには本当に魅力的なものがあります。私は、最新のものを魔法のように保持する一種のキャッシュとして、マテリアライズド・ビューを見ています。マテリアライズド・ビューは、キャッシュ無効化の複雑さをすべてアプリケーションに取り込む代わりに（競合状態とすべての問題を危険にさらす）、キャッシュ・メンテナンスはデータ・インフラストラクチャの責任であるといいます。
- したがってこれについて考えてみましょう：マテリアライズド・ビューを再現し、近代的でスケーラブルな方法で実装し、キャッシュ・メンテナンスの一般的なメカニズムとして使用できるだろうか？既存のデータベースの歴史上の問題がなくクリーンな状態で開始した場合、アプリケーションの理想的なアーキテクチャーはどのように見えるだろうか（図5-17）？
- 図5-2。クリーンな状態で始まった場合、マテリアライズドビューどのようにみえるだろうか？
- 3章では、ログを圧縮したKafkaトピックのイベントを使用して完全に新しいインデックスを作成し、ログからイベントを連続的に消費してインデックスに適用することで最新の状態に保つことについて説明した。これを索引、キャッシュ、マテリアライズド・ビューのいずれと呼んでも大きな違いはない。これらはすべてログ内のデータの派生表現だ（図5-18）。
図5-2。索引、キャッシュおよびマテリアライズド・ビューは、すべて読取り最適化構造化されたログの投影だ。
違いは、インデックスは通常イベントから1つのフィールドを抽出し、それをルックアップ・キー（図5-6）として使用して作成するのに対して、キャッシュまたはマテリアライズド・ビューを構成するにはより複雑な変換が必要な場合がある。
- マテリアライズド・ビューでは、複数のソースのデータを非正規化オブジェクトに結合して、読込み時に結合を実行する必要がない。たとえば、図1-17では、各ツイートには作者のuser_idのみが含まれているが、ツイートを読むときは、ツイートをユーザープロファイル情報（ユーザー名、プロフィール写真など）と結合したい。
- マテリアライズド・ビューには、合計またはカウントなどの集計関数（図1-20のLike数、図2-10の未読メッセージの数など）を含めることができる。
- （たとえば、ユーザーのプライバシー設定を守るために）適用される任意のビジネスロジックが必要な場合がある。
- ストリーム処理フレームワークでは、このような結合、集約、および任意のビジネスロジックを実装することができる。
それでは、マテリアライズド・ビューがキャッシュとどのように異なるかについても明らかにしよう（図5-19）。
- 図5-19アプリケーション管理されたリードスルー・キャッシュに対するマテリアライズド・ビューの利点
- 説明したように、アプリケーション管理されたリードスルー・キャッシュは、アプリケーション・コードによって直接無効化または更新されますが、マテリアライズド・ビューはログを消費することによって維持される。これにはいくつかの重要な利点がある。
- キャッシュ・ミスが発生した場合、キャッシュは必要に応じて満たされる（したがって、特定のオブジェクトに対する最初の要求は常に遅く、図5-10で説明したコールド・スタートの問題がある）。対照的に、マテリアライズド・ビューはあらかじめ計算されている。つまり、コンテンツ全体はインデックスのように誰かがそれを求める前に、その計算されている。つまり、キャッシュ・ミスなどはない。マテリアライズド・ビューにアイテムが存在しない場合、そのアイテムはデータベースに存在しない。背後にあるデータベースにフォールバックする必要はない。（これは、ビュー全体がメモリ内になければならないわけではなく、インデックスと同様にディスクに書き込むことができ、ホットパーツはオペレーティングシステムのページキャッシュ内のメモリに自動的に保持される）。
- マテリアライズド・ビューでは、書込み最適化されたログのイベントを取り込み、ビュー内の読込み最適化表現に変換する明確な変換プロセスがある。対照的に、典型的なリード・スルー・キャッシュ・アプローチでは、キャッシュ管理ロジックはアプリケーションの他の部分と深く織り交ぜられているため、バグが発生しやすくなり、根拠がわかりづらくなる。
- 変換プロセスはストリームプロセッサで実行され、残りのアプリケーションとは独立してテスト、展開、モニタ、デバッグ、スケーリング、および保守が可能だ。ストリームプロセッサはイベントをログの順番に消費し、レースコンディションの影響を受けにくい。失敗して再起動された場合、中断した場所から続行するだけだ。悪いコードをデプロイしてしまったら、履歴データでストリームプロセッサを再実行して、間違いを修正できる。
- ログ圧縮を使用すると、最初からストリームを処理することで、新しいインデックスを作成できる（図3-7）。マテリアライズド・ビューも同じだ。既存のデータを新しい方法で表示したい場合は、新しいストリーム処理ジョブを作成し、入力ログを最初から使用して、既存のすべてのデータを使って、まったく新しいビューを作成するだけだ。両方のビューを並行して維持し、徐々にクライアントを新しいビューに移動し、2つのビュー全体でA / Bテストを実行し、最終的に古いビューを破棄することができる。これ以上に慎重なstop-the-world schemaの移行はありません。
