ストリーミング・データベース

第6章. 一貫性

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

もしあなたがデータベースに精通しているのなら、一貫性は当然だと思っているはずだ。クエリの結果が入力データと一貫していることは知っているはずだ。では、データベースからストリーミングの世界へ橋を渡るとしよう。低遅延と高スループットが重視されるだけでなく、データの到着が遅れたり順序が違ったりするという複雑さが加わっても、同じような一貫性が保証されると信じられるだろうか？

古典的なストリーム・プロセッサでは、答えはノーである。ストリーム・プロセッサは、偶発的一貫性（eventual consistency）と呼ばれる 。ウィンドウ化されたデータの集計を含むことが多い古典的なストリーム処理のユースケースでは、偶発的一貫性は完璧にフィットし、超低遅延、超高スループット、超大規模でのデータパイプラインを可能にする。問題は、もしあなたがデータベースの世界から来たのであれば、偶発的一貫性は、特にウィンドウのないデータとの組み合わせにおいて、混乱し、直感に反する経験になる可能性があるということである。

この章では、Flink、ksqlDB、Protonのような最終的に一貫性のあるストリーム・プロセッサーにおいて、データベースの世界からの直感に従っただけでは何がうまくいかないかを、銀行領域のおもちゃの例を使って実証する。

興味深いことに、最近のストリーム処理システムの中には、より強い形の一貫性 をサポートしているものがある。¹これらのストリーム処理システムのうち、RisingWave、Materialize、およびPathwayを同じジョブに割り当てて、典型的なデータベース・エンジニアの直感により近い方法でおもちゃの例を解くことができるかどうかを確認した。

この章では、最終的な一貫性のパスをたどったときに、いったい何がうまくいかなくなるのか、そして、より強力な一貫性保証を提供するストリーム処理システムが、実際にはどのようにうまくいくのかを詳しく説明する。

最後に、Flinkのような古典的なストリーム・プロセッサが、より強力な一貫性保証をサポートすることに意味があるのかという問題に目を向ける。言い換えれば、低遅延と高スループットを実際にどの程度あきらめなければならないのか、そしてその価値はあるのか、ということである。

玩具の例

この 章は、内部一貫性に関するJamie Brandonのブログから引用したおもちゃの例によって活気づく。この例は、意図的に古典的なストリーム処理の使用例ではない。ウィンドウ処理ではないし、古典的なストリーム処理システムではすぐに利用できない同期を必要とする。この例を選んだ理由は、本書では、ストリーミングとデータベースの融合におけるストリーミング・データベースに興味があるからである。そして、この収束が本当に行われるためには、ストリーム処理システムは、特に一貫性に関して、データベースの世界に匹敵する方法で、非定型で非ウィンドウのユースケースを扱えるようになるべきだと考えている。

10個の口座を持つ銀行があり、各口座が継続的に1ドルを他の銀行口座に送金しているとする。これは表6-1のようになり、各「取引」列は借方と貸方を実行する取引である。左側の「口座」と「開始値」の列は3つの口座、すなわち1、2、3を示し、開始値は$0である。借方と貸方の取引を表すすべての列について、すべての行の合計がゼロになるはずである。 ...