Chapter 2 Solving the Data Integration Problem †
要約 †
(これからまとめる)
詳細 †
この章の始めからデータ統合の問題に戻りましょう。お互いに同期させる必要のある異なるデータストア、キャッシュ、およびインデックスが混在しているとします（図2-3）。
ログの実用的なアプリケーションの例を見てきましたが、私たちが学んだことを、より良い方法でデータ統合を解決する方法を理解するために使用できますか？
図2-29。二重書き込みをやめてしまうとデータが矛盾することになります。
まず、二重書き込みをやめる必要があります（図2-29）。説明したように、潜在的な競合状態やアプリケーションで発生する可能性のある部分的な障害について非常に注意深く考えない限り、おそらくデータが不整合になる可能性があります。
この矛盾は、単に非同期システムで引用される「最終的な一貫性」の一種ではないことに注意してください。ここで私が話していることは、永続的な不一致です.2つの異なるデータストアに2つの異なる値を書き込んだ場合、競合状態または部分的な失敗のために、その違いは単に解決されません。データの不一致を検索して解決するためには、明示的な処置を取らなければなりません（データが絶えず変化しているため困難です）。
私が提案しているのは、アプリケーションがさまざまなデータストアに直接書き込むのではなく、データをログ（Kafkaなど）に追加するだけです。このデータのさまざまな表現（データベース、キャッシュ、インデックス）は、ログを順番に使用することで構築されます（図2-30）。
図2-30。アプリケーションにログにデータを追加させるだけでなく、すべてのデータベース、インデックス、およびログをログから順に読み取って構築します。
同期されている必要がある各データストアは、ログの独立したコンシューマです。すべてのコンシューマは、一度に1レコードずつログ内のデータを取り出し、それを独自のデータストアに書き込みます。ログは、コンシューマがすべて同じ順序でレコードを参照することを保証します。同じ順序で書き込みを適用することによって、競合状態の問題はなくなりました。これは、前に見たデータベースの複製に非常によく似ています。
しかし、部分的な障害（図2-11）の問題はどうでしょうか？あなたの店の1つに問題があり、しばらく書込みを受け入れることができない場合はどうなりますか？
この問題は、ログによっても解決されます。各コンシューマは、ログを処理したログの位置を追跡します。データストア作成コンシューマのエラーが解決されると、最後の位置からログ内のレコードの処理を再開し、発生したすべての情報に追いつくことができます。そうすれば、データストアはたとえオフラインであっても更新を失うことはありません。 1つのデータストアに問題があっても、残りのシステムは影響を受けません。
必要に応じて、完全に新しいキャッシュまたはインデックスをブートストラップするためにログを使用することもできます。これが第3章でどのように動作するかについて説明します。
ログは馬鹿げた簡単な考えです。あなたの書き込みを総合の順序で入れ、すべてのコンシューマに同じ順序で表示します。私たちが見たように、この単純な考えは非常に強力であることが分かります。
担当者のつぶやき †
みんなの突っ込み †
