MakingSenseofStreamProcessing
レプリケーション (Replication) †
要約 †
- レプリケーションログの変更イベントは、実際にはイベントソーシングの意味でのイベントと非常によく似ている。
詳細 †
- 既に第2章でレプリケーションについて説明し、リーダーベースのレプリケーションでレプリケーションログを使用してデータ変更をフォロワーに送信することをみてきた（図2-18）。第3章ではアイデアを再考した。チェンジデータキャプチャは、フォロワーが同じデータベースソフトウェアの別のインスタンスではなくて異なるストレージテクノロジーであることを除いては、レプリケーションと似ている。
このような複製ログは実際にどのように見えるのか？たとえば、図1-10のショッピングカートの例を取りあげる。ここでは、Customer 123がカートを変更してProduct 999の数量3を追加するようにする。更新はリーダー上で実行され、フォロワーにレプリケートされる。フォロワーがこの書き込みを適用するいくつかの異なる方法がある。1つのオプションは、同じ更新クエリをフォロワーに送信し、データベースの自身コピー上で同じステートメントを実行することだ。もう1つの選択肢は、リーダーからフォロワーへの先行書き込みログ（Write-ahead log）を送ることだ。
レプリケーションのための３番目のオプションは、論理ログと呼ばれ、ここではこれにフォーカスする（図5-2を参照）。この場合、リーダーはクエリの持つ効果、つまり、どの行が挿入、更新、または削除されたかをdiffのように書き出す。
- 図5-2。レプリケーションログのロジカルチェンジイベントは、変更された行とその新しい値が必要なものを示す。
- この例のように更新の場合、論理ログは変更された行（主キーまたは何らかの内部タプル識別子を使用して）を識別し、その行の新しい値を返す。
- これは特別なものではないように見えるかもしれないが、面白いことが起こったことに気づくだろう（図5-3）。
- 図5-3。論理複製ログでは、命令コマンドはイミュータブルな変更イベントに変換される。
- 図5-3の上部には、stateステートメントを記述した命令文であるupdateステートメントがある。これは、特定の条件に一致する行を変更するようにデータベースに指示する。
- 一方、論理ログの一部としてリーダーからフォロワーに複製されると、別の形式が取られる。特定の時点で特定の顧客がカート内の特定の製品を1から3に数量を変更したというイベントになる。これは事実だ。たとえ後で顧客がカートからアイテムを取り出したり、数量を再度変更したり、離れて戻ったりすることなく、この状態変化が起こったという事実は変わらない。事実は常に真実のままだ。
- レプリケーションログの変更イベントは、実際にはイベントソーシングの意味でのイベントと非常によく似ている（第1章）。したがって、従来の方法でデータベースを使用して、古い状態を新しい状態で上書きする場合であっても、データベースの内部レプリケーション・メカニズムは、それらの命令文を依然として不変イベントのストリームに変換している可能性がある。
- さしあたりはこのことをおぼえておきなさい。いくつかの異なることについて話をし、後にこの考えに戻るつもりだ。
