大規模な構造化クエリ言語 (SQL) は、構造化されていない、保守不可能なデータベース コードにつながる可能性があります (少なくとも Google に関する限り)。そのため、この業界に所属する科学者は、SQL をより保守しやすいものにするためのオープン ソースの論理プログラミング言語を考案しました。
「良いプログラミングとは、小さくて理解しやすく、再利用可能なロジックを作成することです。これらのロジックはテストでき、名前を付けてパッケージにまとめることができ、後でより有用なロジックを構築するために使用できます」と、Googleのソフトウェアエンジニアであるコンスタンティン・トレチャコフとエフゲニー・スクヴォルツォフは、Googleのオープンソースブログへの投稿で説明しています。「SQLはこのワークフローに抵抗します。」
Tretyakov 氏と Skvortsov 氏は、SQL で使用される英語の単語の連鎖の代わりに数学的な命題論理の構文を使用してデータベースのやり取りを作成するために、Logica という適切な名前の新しいオープンソースの論理プログラミング言語を使用することを提案しています。
少なくともクラウドデータウェアハウスでは、SQLはOracleにとって忌み言葉となっている
続きを読む
Logica の開発者によると、Logica は「Logic with aggregation（集約を伴う論理）」の略称です。GitHub でのプロジェクトの説明では、対象ユーザーがより明確に示されています。「Logica は、BigQuery で実行するクエリやパイプラインを作成する際にロジックプログラミング構文を使用したいエンジニア、データサイエンティスト、その他の専門家を対象としています。」
Logica のコードは SQL にコンパイルされ、Google はこれを同社のデータプラットフォームである BigQuery で実行できるようにしたいと考えています。Logica はローカルでも実行でき、SQL は移植可能です。また、PostgreSQL と SQLite をターゲットとする実験的なサポートも提供されています。
この言語は「より簡潔で、SQL にはないクリーンかつ再利用可能な抽象化メカニズムをサポートしている」と Tretyakov 氏と Skvortsov 氏は言う。
基本的なクエリは、Logica コードでは次のようになります。
MagicComment(comment_text:) :- `comments`(user_id:, comment_text:), user_id == 5;
SQL での同等のものは次のとおりです。
コメントから comment_text を選択します。WHERE user_id = 5;
Logica は、Google が社内で開発し、2015 年に議論された Yedalog と呼ばれる Datalog のような言語の後継であり、大規模な半構造化データセットをクエリするためのツールを提供しようとしました。
トレチャコフ氏とスクヴォルツォフ氏は、Yedalog に後継が必要だった理由については説明していないが、Yedalog の開発者による 2016 年の論文 [PDF] では、Google の Yedalog 実装により、通常はより汎用的な言語を扱う担当者に委ねられる制御の決定が自動化されたと示唆されている。
運用責任の所在が不明確になったため、Yedalogの開発者は運用モデル案をまとめたドキュメントを作成しました。しかし、ユーザーは読むのではなく経験を通して学習し、その経験がYedalogチームが予期していなかった想定を抱かせたことが判明しました。
「彼らが学習したモデルは、私たちがサポートする予定だったものを超えた何らかの形の自動化を想定している」と論文は説明している。
最近の Google での Yedalog の現状がどうであろうと、Logica は、データベース コードをより扱いやすい部分に分割できることを願って、冗長な COBOL スタイルの大文字英語から形式論理の言語へと移行することを目指しています。
「ロジックを一口サイズに分解することに対するこの本質的な抵抗が、不自然で長いクエリ、コピー＆ペーストされたコードの塊、そして最終的には保守不可能で構造化されていない（皮肉なことに）SQL コードベースにつながるのです」とトレチャコフとスクヴォルツォフは皮肉を込めて言う。®
