わさっきhb

大学(教育研究)とか ,親馬鹿とか,和歌山とか,とか,とか.

GQL

大学院,より正確には所属するクラスタ修士論文発表会は昨日,無事終了.
部屋に戻って何通かメールを送り,帰りの支度をしていると,馴染みの先生がいらした.
私の受け持ち学生の一人の内容を,心配なさっていた.最終発表以前に,年2回の小ゼミでもその都度,質問やアドバイスを送っていたので,思うところも強いのだろう.
途中,「先生は,GQLをご存じですか?」と尋ねられた.戸惑いながら「いや,えっとあれのことかな? いや分からないや.すんませんが教えてもらえますか」と答えた.
かいつまんで説明をいただいた.次の2つ(3つ)で,概略はつかめるかと.

それは関連研究として,学生の修士論文の最終版までに取り入れさせたほうがいいですね,どうもすみませんでした,なんてことを言って,いくつか別件の会話をした.
話を聞く途中で,どうやらその学生の研究の方向性と異なっていそうだとも感じた.
もう発表会を終えたので,公知とみなせるし,来月の総合大会のプログラムにタイトルも載っているので,何をした研究なのかを書いておくと,SQL文をNoSQLのクエリ*1に変換する,code wrapperを開発したのである.
といっても,あらゆるSQL文を対象とし,あらゆるNoSQL(非リレーショナルデータベース)向けの変換ができるなんてわけがない.こういうときの書き方は,確立されている.システムの「提案」として,概略を述べる際には,限定しないように整理する.「大風呂敷を広げる」と呼ばれるやつだ.そして実装や評価のところで,入出力を限定する.そうすると,めざましい成果と言うには見た目,弱いわけだが,考察の中で,言い訳にならないように対処する.
なぜそんな変換をしようと考えたのかというと,NoSQLの問い合わせ文は実装ごとに異なり,一つのストレージを使いこなそうと思ったら,それに応じた文法を学ばないといけない*2という煩雑さがあるから.ただし,まったく新規というわけでもなく,過去の研究室内の成果をもとに,何か面白いことをしてみようという思いがあった.
そんな状況で,GQLはというと,Google App Engine向けのSQLライクな問い合わせ言語であり,悪く言えば,NoSQL乱立の原因がまた一つ,追加されたようなものである.
とはいえ「SQLなら多くのデータベースシステム開発者は書ける」という,開発動機のレベルでの共通点はある.したがって,かの学生の研究からすると,強大な敵というよりは,大きな(究極的な解決はおそらく困難な)問題解決のための兄弟のようなものだ.関連研究に書くのが妥当でしょう.
帰りのバスの中で,思い出した.code wrapperとGQLの違いを言うための,また別のアプローチである.
自分のD3のころに遡る.1本,論文を通せばD論を出せると言われ,塾や家庭教師のアルバイトを怠ることなく,紙と鉛筆の研究を頑張った.去年9月に書いた件である.投稿結果は,条件付き採録.その採録条件の一つだったと思うが,Bellare & Rogawayの論文と比較せよというもの.Bellare - Random oracles are practicalだと思う.
修正稿では,その文献を付け加えた上で,「その研究は,random oracleモデルに基づき,証明可能な新たな暗号プロトコルを設計するためのものであり,既存の暗号プロトコルの安全性を検証・判定することは,含まれていない」といった趣旨のことを書いた.他の採録条件にも誠実に対応し,D3の年末に,採録通知をいただいた.
今回の学生の研究に当てはめると,こうなる:「GQLは,SQLライクでGAE向けのクエリを新たに書くためのものであり,既存のデータベースシステムにあるSQL文を,ターゲットとなるストレージ向けのクエリに変換することは,含まれていない」.
こう書いてしまうと,既存の技術をばっさり切り捨ててしまうように見える.自分の研究成果をより良く,より高度に見せるためには,そういったアピールの仕方も,できないといけないのだろう.
しかしその種の切り捨て表現には,抵抗感もある.
齢を重ねるとは,こういう経験や,知識の積み重ねを含むということなのだろうか.


追加:Google Scholarで,「GQL」で検索しても,Googleの文献が見当たらない.上位にいくつか現れるGQLは,graphical query languageの略で,どうみても別物.かつて文献調査をして,昨夜,頭の中で重ね合わそうとしたのは,これだったか.

*1:クエリは,受け渡しを含む問い合わせ全体を指し,問い合わせとして送られるメッセージは例えば「問い合わせ文」と書いて,区別すべきかもしれないが,本日のエントリでは「クエリ=問い合わせ文」としている.

*2:他の研究テーマとつながる問題意識なのだが,同一のストレージであっても,言語仕様や処理系がバージョンアップするなどして,新しい書き方に対応したり,古い書き方でも動作確認するだとかいったことも,考えておかないといけない.