お蔵入りした NoSQL プロジェクトの話

Introduction

「NoSQL」このキーワードが世にはじめて出たのは 1998 年とのこと。だが、当時はほとんど浸透しなかったらしい。そして、2009 年初頭に、ある人物によって再提唱されてから NoSQL は徐々に普及しはじめる。

つい先日、自分のソースコードを整理していたら、最終更新日が 2004 年 11 月のソースコードに目が止まった。そのソースコードは、近年では「ドキュメント指向 DB」と呼ばれる NoSQL のスクラッチソースコードだ。 NoSQL の初提唱が 1998 年で、我々が、NoSQL らしきプロジェクトを開発していたのは 2003 〜 2004 年。 NoSQL が世の中へ普及し始めたのは 2009 年で、世の中へ普及したのはそのもっと後だろう。要するに NoSQL が普及しはじめる 5 年以上も前のプロジェクトの話である。いまからもう 15 年以上前の話である。

このソースコードを見て改めて感じたことは「こういう技術的イノベーションのアプローチは決して間違ってない」ということだ。そして、その時に私たちが発明した技術が、私がいま携わっている AI 研究にも役立っている。イノベーティブな技術者たちには、あきらめないで欲しい。そして、いまの NoSQL 技術に尽力した技術者たちに感謝をしたい。

IfDB

少しだけこのプロジェクトの概要を紹介する。このプロジェクト名は、下記のように何回か遷移した。

FileDB -> IniDB -> IfDB

当時、我々は NoSQL という言葉を全く意識していなかった。それどころか、おそらく我々はそのような言葉を知らなかったはずだ。データの CRUD 処理は以下のような流れだ。

配列 -> クエリコマンド -> Ini File -> 結果セットの配列

そして、我々は SQL ライクな構文まで実装した。そして我々が重視したことの一つは、コマンド経由ではなく Ini File の直接編集も可能にすることだった。なぜなら、当時 Json は汎用的じゃなかったからだ。この技術は、今でも用途によっては有用ではあるが、私は他のプロジェクトで忙しくなりこの 10 数年間忘れていた。しかし、この技術によって、当時の私のプロジェクトの開発速度と改善サイクルが非常に向上したという記憶がある。

Why was the IfDB developed?

15 年前の我々は、なぜこんなものを作り始めたか？私は、このプロジェクトのソースコードを久しぶりに見たが、コンセプトは今のドキュメント指向 DB とたいして変わらない。 15 年前の私は、関係モデルの設計が非常に面倒だったが、ウォーターフォール的なデータモデル設計やスキーマの制約に疑問をもっていた。なぜなら、関係モデルとスキーマが静的化されることにより、プロジェクトのスケーラビリティが損なわれるからである。当時、DBA たちはみんな口を揃えてこう言った。