NoSQLは、乱暴に言えば「何でもかんでもRDBMS使うのは止めようぜ」運動のことである。「Yes SQL!」キャンペーンに反発して地下に潜った反体制組織のことではない。
データベースのモデルとして階層型データモデルやネットワーク型データモデルを押しのけて一般化した関係モデルだが、一般化しすぎた弊害として、関係モデルが向いていない用途にまで採用されることとなった。当然ながら、そのやり方は禍根を残してしまう。
そうではなく、RDBMSが不向きな用途には別のDBMSを使おう、その為にも関係モデル以外のDBMSの開発・改良・普及に力を入れようぜ、というのがNoSQLである。
そう、認めよう。幼少の頃から対人関係すら持て余したまま今に至るボッチなオサーンたる我々が「関係」を扱うだなんて、そもそも無理がある話だったのだ*1。関係モデルに向いていない我々は、必然的にRDBMSにも向いていない。やはりここは別のDBMSを使うべきだ。
RDBMS以外の選択肢
とはいえRDBMS以外の選択肢には何があるのだろうか? 何かと絆が重視され、ボッチという蔑称がはびこる昨今だが、しかし振り返れば奴らがいた。
COBOL
かの偉大なるCOBOL時代には、順編成・索引編成という名のファイルの下に、誰もが日々固定長レコードを捏ね繰り回していた。ソート、ソート、ソートアンドクイック。キー値順に整列されたレコードを舞台にむくつけきプログラマが繰り出す1対nマッチングやコントロールブレークといった秘伝の技は、未だもって基本情報技術者の門をくぐろうとする若者たちに立ちはだかる大いなる壁の役割を果たし続けている。
……まあ正直なところ、COBOLがクソだと言われる諸々は、30〜40年以上前のコンピュータの貧弱さと、当時の開発技法およびツールの未熟さと、その頃のCOBOLの言語仕様の微妙な所と、現在なら別の言語を使うだろう部分までCOBOLで構築してしまった若さゆえの過ちと、老舗旅館の増改築も真っ青な第1次〜第N次改修によるソースコードのキメラ化と、互換性やら検証の手間やらで新機能を使えず古い言語仕様ベースでコードを継ぎ足して今に至る歴史の積み重ね、それらがカクテルのように混ざり合って芳醇な一大システムと化している所に原因があるのではないかと外野として思うのだ。
用途によるだろうけど、モダンな手法に立脚したCOBOLの利用なんてのも新規開発ではありではないだろうか? あ、でもUnixやWindows Serverでのファイルの扱いはどうなるんだろう?
MUMPS
マサチューセッツ発、全米を震撼させた脅威のテクノロジー「MUMPS」が日本上陸! 黒船到来に揺れるニッポンSI業界の明日はどっちだ!
――という夢を見た。その出自ゆえに医療分野では使われているようだが、他の分野では依然としてマイナーなままだ*2。それに黒船到来するまでもなく、既にSI業界は「明日はどっちだ」状態だよね(多分に偏見あり)。
MUMPSのデータベースは、型を持たない*3データを保持する永続的な多次元連想配列だ。こう書くと、何だかサーバサイドでスクリプト言語と組み合わせて使用する前提のNoSQLの実装のように見えてくるから不思議だ。実際のブツは、1960年代末にマサチューセッツ総合病院で開発されたプログラミング言語兼実行環境で、時代が時代だけにソースコードは公開されなかったが、仕様が公開された上にANSI規格になった*4。
MUMPSは、公開された仕様を元に独自の実装を開発・販売するベンダーが複数現れた後、買収や合併を経て数社に減った。現在ではInterSystemsのCachéとFISのGT.Mが市場を2分しているようだ。Cachéはプロプライエタリだが、GT.MはGNU AGPLで公開されている。
GT.Mが普及するか又は別のオープンソース実装が出てくるなりした上で、他の言語からのバインディングが充実すれば、Webアプリ分野での採用例も出てくるのではないかしらん。
XMLデータベース
「XMLは素晴らしい」
彼は言った。
「――いずれSQLはXMLに置き換えられるだろう」
2005年ごろの話だ。しかし置き換わることは無かった。
RDBMSはハードウェアが貧弱な時代により高速なDBMS(階層型モデルの実装とか)に囲まれた状態で生まれた上に、年月も経ているので、性能面で鍛えられている実装も多い。一方、XMLDBは仕組みとしてRDBMSよりも多いリソースを要求する。XMLDBが喧伝されていた頃はCPUもメモリも性能がうなぎ上りだったが、XMLDBが要求するリソースはそれ以上だった。性能要求が足を引っ張ってしまった側面は、(それだけが原因ではないものの)否定できないだろう。
まあでもXMLDBは使われる所では使われている。出版・印刷業界では、SGMLからXMLに移行した所も多いだろう。ハードウェア性能もXMLDBを満足させるレベルになった。XMLDBはDBMSのメインストリームにはならなかったが、特定の分野では着実な成果を上げている。
DBMSから離れた分野では、XMLはそこそこ成功を収めているように見える。内部でXMLを使用しているアプリケーションは多い。クロスプラットフォーム・アプリケーション開発で設定ファイルをどうするか考えた時、仕様が存在して可搬性があり且つ実績のある操作用ライブラリが存在するドキュメント・フォーマットはXMLぐらいだ。
なお個人的にはxsltproc(1)等と組み合わせてシェル芸に持ち込むのが好き。ruby(1)の-eオプションやawkのように、引数にXSLTを書けるツールがあったら最高なんだけどなあ。
ユニケージ
ユニケージ、それはUnixerの愛と欲望の結晶で危険が危ない死亡遊戯である。あ、いや、中身は堅実なんですけどね。
「Unixの可変長テキストレコードによるデータベース・システム」というアイデアは昔から存在した。例えばDouglas Comerの1982年の論文“The Flat File System FFG: A Database System Consisting of Primitives”では、シェルとawkを用いてフラットファイルデータベースを実現し、性能測定等を行っている。
それを除いても、Unix環境の設定ファイルの類は基本的にテキストレコードであるし、その手のテキストの処理に向いているツールが揃っているし、そんな環境で育った開発者は自然とテキストレコードを使うようになるし……それを業務システムに流用したらどうなるか、という発想に至っても不自然ではない。
世の中を見回しても、例えばモガミ電線のようにUnixで事務処理をしてきた企業が存在する。モガミ電線では、公開されている情報を見た限り、シェルスクリプトとawkとテキストレコードを活用しつつ、時にC言語を使ったり、awkライクな自作言語を用いたりして、自社に合致した事務処理の自動化を進めてきたようだ。
技術的な視点においては、ユニケージは従来のUnixテキストレコードの文化を踏襲しつつ、周辺環境の変化や業務システムの特性に合わせて再構築している。更に、事務処理向けに汎用性の高いプリミティブなツールを用意している。*5
ハードウェア性能もカーネル/ファイルシステムの実装も向上に向上を重ねた現在、CPUコアやファイルシステムを使い倒す方針も、時と場合によっては間違いではないのだろう。
まとめ
『7つのデータベース 7つの世界』読みなさい、君ィ。