nbsp;UnQL (Unstructured QueryLanguage、非構造的問い合わせ言語)はドキュメントデータベース向けの問い合わせ言語だ。このプロジェクトは一般に公開されている。というのは、プロジェクトの創始者であるSQLiteの作者のRichard Hipp氏、CouchDBの作者のDamien Katz氏はこの言語が特定のベンダ依存になるのを避け、コミュニティの力で開発したいと思っているからだ。固定的なテーブルで構成されている関係データベースとは違って、ドキュメントデータベースはJSON形式で表現されたコレクションを持つ。しかし、UnQLは機能的にはSQLのサブセットとして実装されており、テーブルをフラットな構造と固定のフィールドを持つドキュメントとして見る。つまり、UnQLはRDBMSへの問い合わせにも使えるのだ。しかし、テーブルの作成/削除、スキーマの変更はできない。
この記事ではRichard Hipp氏へのインタビューをお届けする。氏はUnQLがチームの努力の成果であり、氏自身は唯一の意思決定者ではないということを知らしめたいと思っている。このインタビューで聞くことが出来た面白い話題は、氏が“SQLiteと同じし思想を持った組み込み可能なドキュメント指向データベース.”としてUnQLiteを作ろうとしていることだ。
InfoQ: なぜUnQLなのですか。どのような問題を解決しようとしているのですか。
RH: UnQLはデータベース用の問い合わせ言語です。SQLと似ていますが、ドキュメント指向データベース向けです。
SQLは堅牢に定義されたデータスキーマを想定しています。各テーブルは固定数の列を持ち、各列のデータ型は異なります。
一方、UnQLはデータを保存することに対して、より柔軟な方法を取ります。UnQLは"テーブル"の代わりに、"コレクション"を使います(概念は同じですが、名前が違うのは"テーブル"は四角ですが、"コレクション"は様々な形を取りうるからです)。各コレクションはJSON形式で表現されるドキュメントを0かそれ以上含んでいます。UnQLでのひとつのドキュメントはSQLのひとつの行に相当します。大きな違いは、UnQLではドキュメント(行)は固定数の列を持たず、列("フィールド"と呼ばれる)は固定の型を持たない、そして、フィールドは入れ子にすることができるということです。例えば、あるフィールドの値として他のドキュメントを格納できます。
現在、いくつかのドキュメント指向データベースが利用できます。そして、人気も上昇しています。しかし、既存のドキュメント指向データベースはすべて、それぞれ固有で互換性のない問い合わせ方法を持っています。つまり、アプリケーションのデータベースエンジンを変えるのはとても難しいのです。さらにこれらの問い合わせ方法はとても低いレベルで定義しなければならない傾向があります。その結果、データベースエンジンによって自動的に処理される問い合わせ処理も、プログラマが自前でアプリケーション内に書かなければならないのです。
UnQLの目的は様々なベンダが提供するドキュメント指向データベースにアクセスできる汎用のデータベース問い合わせ言語を提供し、このような状況を改善することです。こうすることで、開発者は移植可能なアプリケーションと書くことができ、ベンダにロックインされることもなくなります。データベースエンジン側に複雑なアルゴリズムを持たせ、アプリケーションのコードと開発者の負担を減らせる、強力でリッチな言語を目指しています。
UnQLのデータの扱い方は機能的にはSQLのサブセットです。なので、理論的にはUnQLは従来のデータベースエンジンでも使えます。UnQLは従来のデータベースエンジンを各フィールドが全く同じデータ型のフラットな構造を持つドキュメントを保持するドキュメント指向データベースと見なします。(SQLのデータ定義言語(DDL)は使えません。従って、UnQLは、例えば従来のデータベースに対してCREATE TABLEやDROP INDEXのような操作は出来ません。insert、delete、update、それに通常の問い合わせは可能です。書式はSQLの制約に従いますが、従来のデータベースのスキーマ変更はできません)
InfoQ: すべてのRDBMSで使えるSQLのような、すべてのNoSQLデータストアで利用できる問い合わせ言語を作りたいですか。
RH: まず、私は"NoSQL"という呼び名よりも、私は"ポストモダンデータベース"という名前が好きです。ポストモダンデータベースはCAP原理を克服するように設計されています。従来の関係データベースは一貫性(CAPのC)に執着します。その結果、可用性とパーティション耐性を犠牲にします。ポストモダンデータベースは一貫性を諦めることで、可用性とパーティション耐性の両方を得ようとします。一貫性を諦めるというのは、客観的事実がないということを示します。客観的事実の不在はポストモダンの特徴です。なので、ポストモダンデータベースという名前なのです。別の言い方をすれば、ポストモダンデータベースに問い合わせをすると、返ってくるのはある事実ではなく、ある見解なのです。
これはポストモダンデータベースを貶めているわけではありません。ポストモダンデータベースは強力であり、全体に需要があります。多くの人々(私も)が最終的には、ポストモダンデータベースがデータベースエコシステム内で支配的になると思っています。しかし同時に、限界を知っておくことが重要です。ポストモダンデータベースを使うことで、一貫した世界を見せ続ける仕事はデータベースからクライアントシステムへ移ります。これによってデータベースエンジンは簡単にスケールアウトするようになりますが、アプリケーションがしなければならないことが増えます。開発者はこのトレードオフを明確かつ冷静に考えて、ポストモダンデータベースの扱う必要があります。
あなたの質問に答えるのなら、はい、UnQLは、関係データベースにおけるSQLのような役割を、ポストモダンドキュメント指向データベースにおいて担いたいと思っています。どのようなドキュメント指向データベースでも利用できる、実務に耐えうる汎用言語を目指しています。
InfoQ: UnQLをCouchDBで使いましたか。使う予定はありますか(D. Katz氏がプロジェクトに参画していますね)。
RH: Damien Katzは近いうちにCouchDBへUnQLのインターフェイスを提供するつもりです。他のデータベースエンジンにインターフェイスを提供する計画も動いています。私は従来のSQLiteにインターフェイスを提供したい思います。そして、SQLiteの思想を受け継いだ組み込みドキュメント指向データベースとして"UnQLite"を作りたいです。もちろん、ファイルのフォーマットは新しくしますが。
InfoQ: UnQLはまだ初期段階ですが、今後の展開はどうなるでしょうか。どこに向かって進むのでしょうか。
RH: 今はざっくりとしたプロトタイプしかありませんが、ユーザからの情報やプロトタイプ実装から得た知見を元に改善を続けていきたいと思います。また、今年中にはこの言語が使えるデータベースをひとつ以上準備し、開発で実際に利用できるようにしたいです。来年には配布できる実装を作りたいですね。
インタビューの最後に、氏はコミュニティこのプロジェクトに巻き込みたいと語った。
RH: 本当に本当にコミュニティからインプットを得たいのです。言語の設計や改善の提案、プロトタイプ実装の手伝いなどのボランティアをしてくれる方を本当に歓迎します。すべてはオープンソースです。
UnQLは少数の企業が自分たちの世界を押し付けながら実装しているわけではありません。複数のデータベースで使える、コミュニティによって作られた言語にし、開発者の負担を軽減したいのです。ポストモダンドキュメント指向データベースの開発と浸透を妨害するベンダ固有のプラットフォームを終わらせるのが私たちの目的です。
UnQLを成功に導くために力を貸してくれませんか。
UnQLは現在、プロトタイプであり、ウェブサイトには構文についての詳細な情報やソースコードやサンプルを含むリポジトリへのリンクがある。