データベースの歴史

社員が 2 つの部署に所属できない

1960 年代の最初のデータベースは、データを木の形で持っていました。IBM の IMS が代表で、アポロ計画の部品管理にも使われています。親の下に子がぶら下がる構造は、部品表のように上下関係のはっきりしたデータとはよく合いました。

合わなかったのは、親が 2 つ必要なデータです。1 人の社員が開発部と品質保証部を兼務する、といった関係が表現できません。木では、子は 1 つの親しか持てないからです。

1970 年前後に登場したネットワーク型は、子が複数の親を持てるようにしてこれを緩めました。ただし今度は、データの並びと「どう辿って取り出すか」がプログラムに焼き付いています。構造を少し変えるだけで、そのデータを触る全プログラムを書き直すことになりました。

当時のプログラムには「まずこの入口を開き、次にこのポインタを辿り、そこから兄弟を順に見る」という道順が直接書かれていました。データの持ち方を変えるということは、書いてある道順を全部書き直すということです。

「どう取るか」を書かなくてよくなった

1970 年、IBM 研究所の E.F.Codd が論文を発表します。主張は「データを集合として扱えば、辿り方とデータを切り離せる」というものでした。使う側は欲しいものだけを書き、どう取り出すかは DBMS が決める。この分離が、いま当たり前になっている書き方の出発点です。

実装したのが IBM の System R とカリフォルニア大学の Ingres で、前者から SQL が生まれ、後者は PostgreSQL の祖先になりました。1979 年に Oracle が商用として登場し、1986 年に SQL が標準化されると、業界は一気にここへ収束します。以後 20 年ほど、データベースといえば RDB のことでした。

1 台に収まらなくなって、また分かれた

2000 年代後半、Google や Amazon が抱えたのは「1 台の RDB に載らない量」でした。マシンを強くする方向には天井があります。そこで台数を並べる方向へ舵を切り、その代償として、書いた直後に読んでも古い値が返りうる状態を受け入れました。買い物かごに入れた商品が数秒だけ表示されないことは我慢できても、全世界の利用者が一斉に待たされるのは我慢できない、という判断です。BigTable と Dynamo の論文が広まり、Cassandra や MongoDB、Redis が続きます。分散したときに何を諦めるかを整理した CAP 定理という言葉が知られるようになったのも、この時期です。

使ってみた現場から出た声は「結合したい」「SQL で書きたい」でした。2010 年代の NewSQL は、複数ノードで合意を取る仕組みを内側に持ち込むことで、台数を増やしながら整合性も保とうとしています。Google Spanner や CockroachDB、TiDB がこの系統です。

いま使っている道具は、どの世代の答えも捨てていません。木構造の発想は JSON を扱う DB に、ネットワーク型はグラフ DB に受け継がれ、SQL という共通語は 40 年生き延びています。どれか 1 つが正解だったのではなく、その時代にいちばん高くついた問題が何だったかで、答えが入れ替わってきただけです。