Looking Forward: Toward Robust Streaming SQL

• ここまで、時間的に変化する関係、テーブルとストリームが時間的に変化する関係をどのように表現するか、ストリームとテーブルの理論に対してBeamとSQLのモデルがどのような固有のバイアスを持つかについて見てきました
• もっと重要なことは、堅牢なストリーム処理をサポートするためにSQL内で何を変更または追加する必要があるかということです。意外な答えですが、「良いデフォルトがあるのであれば、あまり必要ありません。」
• 重要な概念的変化は、古典的なポイントインタイムの関係を時間的に変化する関係に置き換えることであることは分かっています。
• これは、関係代数の重要なクロージャ特性を維持することで、既存の関係演算子の全範囲に渡って適用できる、非常にシームレスな置換であることを先に述べました。
• しかし、時間的に変化する関係を直接扱うことは現実的でないことが多いので、より一般的な物理的表現であるテーブルとストリームで操作する機能が必要であることもわかりました。そこで、良いデフォルトを持つ簡単な拡張機能が必要になります。
• また、時間、特にイベント時間についての推論を堅牢に行うためのツールも必要です。ここで、タイムスタンプ、ウィンドウ、トリガーといったものが登場します。しかし、ここでも、デフォルトの賢明な選択が、これらの拡張が実際に必要となる頻度を最小にするために重要であろう。
• 素晴らしいのは、これ以上何も必要ないということです。それでは、最後にストリーム/テーブル選択と一時演算子という2つのカテゴリの拡張機能について詳しく見ていきましょう。

Stream and Table Selection

• 時変リレーションの例では、ストリームとテーブルの選択に関連する2つの重要な 拡張にすでに遭遇しています。それらは、SELECTキーワードの後に置いたTABLEとSTREAMキーワードで、与えられた時変関係の望ましい物理的な見方を指示するものでした。

• これらの拡張機能は比較的簡単で、必要なときに簡単に使うことができます。
• しかし、ストリームとテーブルの選択に関して本当に重要なことは、それらが明示的に提供されていないときのために、良いデフォルトを選択することです。
• このようなデフォルトは、誰もが慣れ親しんでいる古典的なSQLのテーブルに基づいた動作を尊重すると同時に、ストリームを含む世界でも直感的に操作できるものであるべきです。
• また、覚えやすいものであるべきです。ここでの目標は、システムの自然な感触を維持しながら、明示的な拡張を使用しなければならない頻度を大幅に減らすことです。これらの要件をすべて満たすデフォルトの良い選択は、次のようなものです。
  • すべての入力がテーブルの場合、出力はTABLEになります。
  • 入力のいずれかがストリームの場合、出力はSTREAMです。
• 追加で重要なことは、このような時間変動する関係の物理的な描画は、TVRを直接表示したり、出力テーブルやストリームに書き込んだりと、何らかの形で実体化する場合にのみ必要だということです。
• 完全忠実な時間変化する関係という観点から隠れて操作するSQLシステムがある場合、中間結果（例えばWITH ASやSELECT INTO文）は、システムが自然に扱うどんな形式であれ、完全忠実なTVRとして残すことができ、他の、より限定的な具象表現にレンダーする必要はないのです。
• そして、これがストリームとテーブルの選択に関する本当のところです。ストリームやテーブルを直接扱う機能だけでなく、SQLの中で堅牢で順不同なストリーム処理をサポートするためには、時間に関する推論を行うためのより良いツールが必要です。では、そのようなツールについて詳しく見ていきましょう。

Temporal Operators