『データベース指向アプリケーションデザイン』の 11 章「ストリーム処理」を読んだのでそのメモ
10 章では、一連のファイルを入力として読み取り、新しく一連の出力ファイルを生成する手法であるバッチ処理 大きな前提が置かれていました。それは、入力が有限であること
日時のバッチ処理で問題なのは、入力に対する変化が反映されるのが 1 日後の出力
イベントが生じるたびに連続的に処理をしたり ストリーム処理
- バッチ処理
- 入力が有限であること
- 入力に対する変化が反映されるのに遅延が発生すること
- ストリーム処理
- 入力が有限でないこと
- イベントが生じるたびに連続的に処理をすること
Google の Dataflow は、ストリーム処理とバッチ処理の両方をサポートしているっぽい ↓ リアルタイム性にもドキュメントでは言及しているので、ストリーム処理の特徴を持っている
https://cloud.google.com/dataflow?hl=ja
11.1 イベントストリームの転送
ストリーム処理の文脈においては、一般にレコードはイベント
GraphQL の Subscription という機能にも通ずるところを感じた
ストリーミングの用語ではイベントはプロデューサー（パブリッシャあるいは送信者と呼ばれることもあります）に一回生成され、複数のコンシューマ（サブスクライバあるいは受信者）によって消費
やはり Pub/Sub の文脈を理解していたら、ストリーム処理という概念の理解も早いかもしれない。 いや、逆も然り？
ファイルシステムでは、ファイル名によって関連する一連のレコードが識別されますが。ストリーミングのシステムでは、関連するイベント群は通常トピックあるいはストリームとしてグループ化
10 章で調べたバッチ処理システムのいいところは、強い信頼性の保証を提供しているところ
あー、なるほど。確かにリアルタイムに処理しておくと、サブスクライバがクラッシュしていたら、データとしては欠落が生じる。 その点バッチ処理は、失敗したとしてもリトライすることで、出力自体は信頼できる。
11.1.1.1 プロデューサからコンシューマへの直接のメッセージング
11.1.1.2 メッセージブローカー
上記二つの実現方法があり、メッセージブローカの方が、耐障害性が上がる。永続性の問題がブローカーに移ることになるが、ディスクに書き込むなどしてブローカーがクラッシュしても大丈夫な仕組みを整えている。
ちなみに、Google Cloud の Pub/Sub は、メッセージブローカーの仕組みを持っている。
https://cloud.google.com/solutions/event-driven-architecture-pubsub?hl=ja
11.1.1.5 承認と再配信
コンシューマがメッセージを受け取っても処理を完了しない可能性もあるので、メッセージブローカーは承認を利用する。
クライアントはメッセージを処理し終えた時点で明治的にブローカーにそのことを伝え、ブローカーがーそのメッセージをキューから削除できるように
ここでいうクライアントは、コンシューマのことであっているかな？
この仕組みも Google Cloud の Pub/Sub にはある記憶。
11.2 データベースとストリーム
データベースの書き込み
何かがデータベースに書き込まれたということは、補足し、保存し、処理できるイベント
この見方は、データベースとストリームとのつながりは、単なるディスク上のログの物理ストレージという以上に深いことを示しています
それは極めて本質的なものなのです
firestore はこの保存とか更新とかのイベントに対してトリガーを張る機能が提供されている。それにまつわることを話すのかな？
11.2.2 変更データのキャプチャ データベースに書かれたすべてのデータの変更を観察し、それが他のシステムへレプリケーションできる形態で取り出すプロセス
これ、やっぱり firestore のトリガーで似たような仕組みが構築できる。
けど、この概念を知っていなければ、こういった設計ができないので、これは知ることができてよかった。
ちなみに「変更データキャプチャ」は、Change Data Capture (CDC) と呼ばれるらしい。
11.3 ストリームの処理
論じなければならないこととして、入手したストリームで何ができるのか、すなわちその処理の方法
これは 3 つ挙げられていて
- イベント中のデータをストレージシステムに書き込み、他のクライアントから利用できるようにする
- メールを送信したり、通知をプッシュしたり、可視化を行うリアルタイムダッシュボードへのイベントをストリーミングしたりする
- 上記のような出力を得るために、パイプする
3 つめがよくわからなかった。と思ったら、3 つ目をこの章で説明するらしい。
11.3.3 ストリームの結合
これかな？イベントだけで意味のある出力を得られるかわからない（例えば、ユーザー ID だけを含んだイベントだけではアクティビティイベントの分析が可能な形にならない）場合、結合というステップを挟む。
- ストリーム - ストリーム結合
- ストリーム - テーブル結合
- テーブル - テーブル結合
んーこの辺りちょっとイメージ湧きづらいな。。
「ストリーム - テーブル結合」は、それぞれのイベントについて、結合オペレータはデータベースに対してクエリを実行して加工されたデータを出力するイメージ。
結合オペレータ、という登場人物がいるらしい。