Chapter 3 Database = Log of Changes †
要約 †
- データベースは変更履歴（ログ）であると極端に考えてみる
- データベースへの変更はイベントのストリーム、ということになる
- データベースへのあらゆる書き込みはストリーム内のイベント、ということになる
- 元のデータベースにコミットされたの同じ順序で他のデータベースに適用すると、完全な複製ができあがる
- これは、データベースのレプリケーションにほかならない（第2章、図2-19を参照）
- リーダーデータベース（マスターデータベース）はレプリケーションログを生成する
- フォロワー（レプリカ）がリーダーへ追いつくために必要な変更の（イベントの）ストリーム
- ストリームを継続的に反映していくことで、リーダーと同期し続けることができる
- 上述のとおりレプリケーションと同じ事を考えている
- フォロワーは、リーダーデータベースとは異なるテクノロジーだけど（検索インデックス、キャッシュ、データウェアハウス）
- レプリケーションはデータベースの備える一般的な機能だが、レプリケーションログは実装依存で、公開APIにはなっていない
- レプリケーションイベントは、アプリケーションからアクセスできるような形式にはなっていない
- 従来型のレプリケーションをするソフトウェア
- リアルタイム指向の変更ストリームに近いレプリケーションをするソフトウェア
- チェンジ・データ・キャプチャ（CDC）
- あるストレージから別のストレージへデータを複製する仕組みのこと
- 対象のデータベースから次のような情報を抽出する必要がある（アプリケーションが利用できる形式で）
- ある時点のデータベース全体の一貫したスナップショット
- スナップショット以降に発生したあらゆる変更（挿入、更新、削除）のリアルタイムストリーム
- CDCを主要な技術要素として開発している会社（とそのプロダクト）
- Kafka の 0.9 リリースから Kafka Connect という API を提供するようになった
- Kafka を他のデータベースなどに接続するための API
- 他のデータベースのスナップショットや変更ストリームを、Kafka に流す
- Databus などを参考にしている
- 変更ストリームにデータベースへの最初の書き込みが含まれるならスナップショットは不要
- しかし、たいていのデータベースはしばらくするとトランザクションログを消してしまう
- したがって、基本的には変更ストリームを取り始める前のスナップショットは必要
担当者のつぶやき †
みんなの突っ込み †
