SQLの問題点と解決策: SQLのパイプ構文

(research.google)

13 ポイント投稿者 GN⁺ 2024-08-26 | 11件のコメント | WhatsAppで共有

SQLは50年にわたり構造化データ処理の基本言語として定着してきたが、学ぶのが難しく、使いこなしにくく、拡張しづらい
従来のSQLの問題点: 構文順序の強制、重複した構文、サブクエリの使用の必要性、「内側から外側へ」というデータフロー、拡張性の不足など
GoogleSQLではSQLの問題を解決するために、SQLを拡張するアプローチを採用
- パイプ構造のデータフロー構文をSQLに導入し、従来のSQLの問題を解決しようとしている
- 既存のエコシステムを維持しながら、より柔軟に学習・利用でき、既存SQLとの完全な互換性を保てる
  - 既存のSQL演算子を再利用し、パイプで任意の順序に構成できるようにする
  - 各パイプ演算子は入力テーブルだけを見ればよいため、スコープが明確
  - 宣言的セマンティクスを維持
  - 関係代数と1対1で対応可能
  - テーブル値関数を用いた拡張性が向上
- たとえば、多段階集計をサブクエリなしで連続的に表現できる
- パイプ構文を使ったSQLは学習と利用がより容易で、さまざまな演算子を任意の順序で適用できるため、柔軟性が大幅に向上する
- パイプ演算子は順次動作し、これによってユーザーはデータをより簡単にフィルタリング、集計、並べ替えできる
GoogleSQLでの利用経験
- ユーザーによる継続的な採用と好意的なフィードバックを得ている
- 複雑なクエリも線形に表現可能
- 編集やデバッグ作業がしやすい
- IDEツールのサポートが改善
- SQLコード生成器や変換器に有利
- AI適用における潜在的な利点がある
実装と今後の計画
- GoogleSQLでパイプ構文を共有コンポーネントとして実装
- 既存のクエリエンジンはパイプ構文を容易に有効化できる
- BigQueryとSpannerで外部向けにサポートすることを検討中
- 将来的にSQL標準へ含めることを模索する価値がある

GN⁺の意見

パイプ構文の利点: SQLの複雑さを解消できる強力な手段として機能し、特にデータフローを直感的に表現できるため、SQLの使い勝手を大きく改善できる。
既存SQLとの互換性: 既存SQLを置き換えるのではなく、SQLを改善する方向でアプローチすることで、学習コストを下げつつ既存コードとの互換性を維持できる。
導入時の考慮事項: パイプ構文を採用する際は、性能への影響とツールサポートの水準を考慮する必要があり、特に大規模クエリでその利点を最大限に活用できる。
類似プロジェクトとの比較: PandasのようなDataFrame APIでもパイプ構造は使われるが、SQLとの違いはSQLの宣言的セマンティクスとの結合にある。SQLシステムの拡張性と性能を維持しながら、この機能を利用できる。

11件のコメント

dkang 2024-08-26

パイプにキャレットとは、なんだか右手が痛くなりそうな組み合わせですね🤣
今のSQLには何らかの改善が必要なのは確かですよね
ここ3〜40年ものあいだ改善案を見つけられなかったのが問題ではありますが..

savvykang 2024-08-26

SQL の追加構文については、エコシステムを Google が主導すべきだと思いますが、果たして事業部がこれを継続させるでしょうか？

chusine 2024-08-26

dplyr ですねｗｗｗｗ

koreaisbest 2024-08-26

なぜグーグルがやると言うと、失敗しそうな気しかしないんだろう..
ジェミニは子どもっぽい感じで回答するから、使う気にもなれない

ilotoki0804 2024-08-26

ORMが取るアプローチと似ているようですね

winterjung 2024-08-26

ペーパーの以下の例を見るだけでも、Google SQL のほうが確かに読みやすいですね。

standard sql

SELECT c_count, COUNT(*) AS custdist  
FROM  
    ( SELECT c_custkey, COUNT(o_orderkey) c_count  
      FROM customer  
      LEFT OUTER JOIN orders ON c_custkey = o_custkey  
           AND o_comment NOT LIKE '%unusual%packages%'  
      GROUP BY c_custkey  
    ) AS c_orders  
GROUP BY c_count  
ORDER BY custdist DESC, c_count DESC;

google sql

FROM customer  
|&gt; LEFT OUTER JOIN orders ON c_custkey = o_custkey  
      AND o_comment NOT LIKE '%unusual%packages%'  
|&gt; AGGREGATE COUNT(o_orderkey) c_count  
   GROUP BY c_custkey  
|&gt; AGGREGATE COUNT(*) AS custdist  
   GROUP BY c_count  
|&gt; ORDER BY custdist DESC, c_count DESC;

mwma91 2024-08-30

C#のLINQを思い出しますね。SQLを書くたびに、SELECTの順序がいつもFROM、WHEREの後ろに変わってくれたらいいのにと思っていましたが……
最初は慣れなくてぎこちなくても、ゆっくり読んでみると流れがずっと自然に感じられます。

regentag 2024-08-27

SQLのほうが読みやすいようですね。

leftliber 2024-08-27

私はSQLのほうがずっと読みやすいですね。笑 SQLから始めた人は、たぶん大半がそうだと思います……

superwoou 2024-08-28

私も慣れているほうが読みやすいですね.. （笑）

GN⁺ 2024-08-26

Hacker Newsの意見

SQLのパイプ構文はより読みやすい
GoogleでSQLクエリを書く際、パイプ構文は有用だった
SQLパイプ構文が一般化されることを望む
Google AI StudioでPDFをHTMLに変換してみた結果は良好だった
20年以上SQLを使ってきたが、今でも特定のクエリを表現するのは難しい
GoogleのオープンソースZetaSQLプロジェクトがパイプ構文のドキュメントを追加した
SQLの構文への不満は優先順位が低い
- 代数的データ型、真のブール論理、関数型構成などの機能が必要だ
SQLを書く難しさを減らすための多くの試みがあったが、成功しなかった
- 著者たちのアプローチは段階的で、既存のSQLユーザーに適している
パイプライン構文は現状より良い
- クエリ実行を作業の有向グラフとしてモデル化する構文のほうがさらに良いだろう
  - JOINは、2つ以上のデータストリームを消費して1つのデータストリームを生成する「相互参照」操作としてモデル化できる
  - CTEは複数のデータストリームを生成するものとしてモデル化できる
  - 再帰CTEは実行グラフのサイクルとしてモデル化できる
Elixirに似ている
- 既存のSQL構文がサポートされるなら問題ないが、複数のJOIN、サブクエリ、集計を含むクエリは可読性が低くなる可能性がある
PRQLやSplunkのSPLを思い起こさせる

SQLの問題点と解決策: SQLのパイプ構文

GN⁺の意見

関連記事

11件のコメント

Hacker Newsの意見