書評：「7つのデータベース 7つの世界」

訳者、角 征典氏より献本御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4j、Redisである。本書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。

正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献本して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。本当に辛口になるのでその点は容赦して頂きたい。

何が問題なのか

本書ではRDBMSの代表としてPostgreSQLについて説明がなされている。皆さんご存知の通り、私はMySQL関係の仕事をしている。「PostgreSQLを扱っているからdisりたいんだろう？」など思われるかも知れないが、そのようなつもりは毛頭ない。何が問題なのか。それは本書のRDBMSとしての説明が根本的に間違っているからだ。まず、第2章の最初のページ（p.9）には次のような説明がある。

PostgreSQLは、リレーショナルデータベース管理システムである。これは集合論をベースにしたシステムで、データ行と厳密に型の決まった列からなる・・・

ここまでは良い。だが・・・

・・・2次元のテーブルとして実装されている。

コーヒー吹いちまったよ・・・。テーブルは多重集合だが、集合論をベースにしたと説明しているのだから、これはリレーション（＝集合）についての説明だろう。リレーションが2次元的な構造を持っているというのは典型的な誤解である。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）いきなりこのような初歩的なミスを犯してくれたおかげで、期待感は一気に崩れ去ってしまった。

さらにぶっ飛んでるのがp.11〜p.12にかけて「数学的リレーション」というコラムだ。このコラムで例として登場するSQLは次のようなものである。

SELECT x.name FROM People x WHERE x.died_at_age IS NULL

よりにもよってNULLかよ〜〜〜ッ！！

今度は椅子から転げ落ちそうになってしまった。

原著者はリレーショナルモデルについてまるで分かっていない。SQLとリレーショナルモデルには大きな乖離がある。少しでもリレーショナルモデルについて学んだことがあるのなら、このようなSQL文を例に挙げることは絶対にない。そもそもNULLはリレーショナルモデルにはない概念だからだ。

コラムでは上記のSQLが次の関係代数の式に相当するという説明がなされている。

πname(σdied_at_age = ω(ρx(People)))

対応する（同じような意味の）式を書いたところで、一体何の説明になるというのだろうか。「こういう書き方ができますよ」というだけであり、リレーショナルモデルがどういうことかについては2つの式を並べたところでサッパリ読み取ることが出来ない。何となく分かったつもりになるというのが関の山だが、この「分かったつもり」というのはとても危険な落とし穴である。まともに理解しようというモチベーションを削いでしまうし、誤解したまま覚えてしまうことにもなるからだ。

以降の説明もとても微妙な感じである。本書では、各データベースを日曜大工のツールになぞらえていて、PostgreSQL（RDBMS）はハンマーのようなものだと説明しているが、ステレオタイプ的な「RDBMSは何でもできるアーミーナイフ的なソフトウェア」という類の説明がなされているように感じた。「PostgreSQLでできること」を説明したものとしてはコンパクトにまとまっているのだろう。「いろんな言語でストアドプロシージャが書けるんだぜッ」「ウィンドウ関数をサポートしてるんだぜッ」「全文検索の方式も選べるぜッ」等々。「だけど、それってリレーショナルモデルとは関係ないよね」と言わずには居られない。

私は「NoSQLはリレーショナルモデルの代替にはならない」と常々考えているのだが、本書はそのような意見ではないらしい。確かにリレーショナルモデルを実践しないなら、RDBMSを使うメリットはかなり下がってしまうだろう。例えそれがアーミーナイフのような万能ツールであったとしてもだ。第2章のまとめ（p.47）にもそのような誤解が色濃く表れている。

PostgreSQLの強み

PostgreSQLの強みは、リレーショナルモデルと同じく膨大だ。長年の研究、あらゆる計算分野における利用実績、柔軟なクエリ、高い整合性と永続性。

（中略）

なかでも重要なのは、結合の柔軟性だ。結合、フィルタ、ビュー、インデックスを使えば、モデルに問い合わせる方法を事前に計画する必要がない。ほしいデータを抽出できる力が常に備わっているからだ。

ちがう。それは違うよ！！

リレーショナルモデルで重要なのは、データベースの設計を堅牢にできることであって、クエリが柔軟な点ではない。事前によくデータベースを設計しないと痛い目に遭ってしまう。しかしデータベースの設計をしっかりやっておけば、データの論理的な整合性を保証することが出来る。それはつまりアプリ側で整合性を確認するロジックを実装する必要がないということだ。このメリットに比べれば他にいくら便利機能があろうと霞んでしまう。ちなみに、PostgreSQLの各種拡張が役に立たないとは思わない。とても便利な機能であり、開発の役にたつことは間違いない。だが、リレーショナルデータベースとしてそれらを紹介するのはいかがなものか。

そんなわけで、本書のRDBMSの説明はナシだと思う次第である。

さらなる問題2点

RDBMSの説明ほど問題ではないが、個人的にかなりイラッと来た説明が2章にあったので紹介しておこう。

p.46「3日目のまとめ」より引用

今日は、PostgreSQLの柔軟な文字列検索に潜り込んで、多次元検索用のcubeパッケージを試してみた。PostgreSQLがオープンソースRDBMS界のトップに君臨しているゆえんである、非標準の拡張の片りんをうかがい知ることができた。手に入る拡張は（数百とは言わないまでも）数十は存在する。地理的空間ストレージから暗号関数・カスタムデータ型・言語拡張までさまざまだ。SQLのパワー以上に、contribパッケージはPostgreSQLを光り輝かせているのである。

マジレスするとそれは事実ではない。だいいちユーザー数ではトップではない。何をもってトップとするのか。それは個人の価値観ではないのか。そもそもある程度の複雑さを超えたソフトウェアは単純に比較することはできない。なぜなら同じような機能でも実装が異なるからだ。そのため機能ごとに強みと弱みが出てくることになる。私はMySQLが好きだが、それでも「MySQLが最強のRDBMSだ」とは言わない。MySQLは優れたソフトウェアだと思うし、ユーザーを獲得することに成功していると思うが、他のRDBMSに比べて苦手とする処理もたくさんあるからだ。よって特定のソフトウェアに対して数値化できない事柄を「トップに君臨する」と表現するのは適切ではない。

p.47〜48「PostgreSQLの強み」より引用

PostgreSQLは純粋なオープンソースソフトウェアだ。誰もコードを所有していない。誰でも何でも好きなことができる（著作権を主張すること以外）。ソフトウェアの開発や配布は完全にコミュニティがサポートしている。あなたが自由なソフトウェアのファンであれば、あるいはモジャモジャのヒゲを生やしているのであれば、彼らが驚くべきプロダクトを無償で提供してくれていることに敬意を払わなければいけない。

私は自由なソフトウェアのファンだしモジャモジャのヒゲ面だが、この意見には同意しかねる。PostgreSQLは制限の弛いPostgreSQLライセンスなので、改良を加えたソフトウェアに対して独自のライセンスを適用し、私有（プロプライエタリ）ソフトウェアとして著作権を主張することが可能だ。現にそのようなソフトウェアはいくつも存在する。（参照：WikipediaのPostgreSQLのページ）開発手法がオープンソース的ということなら同意するが、自由なソフトウェアとしてはいかがなものか。（気になってFSFで紹介されているライセンスの一覧を見てみたが、残念なことにPostgreSQLライセンスは見当たらなかった。FSFが認知していないライセンスの適用されたソフトウェアを自由なソフトウェアとして紹介するのはいかがなものか。GPLの拡張もあるけどライセンスの互換性は大丈夫なのか？せめてGPLとのデュアルにすべきではないのか？このへんの経緯に詳しい人が居たら事情を教えて欲しい。）

恐らく原著者はPostgreSQLのファンなのだろう。PostgreSQLは優れたオープンソースのRDBMSであり、その点は強く同意する。だが、あまりにも盲目的になりすぎて、誤った賞賛をしてしまっているのではないだろうか。

本書の構成

第3章以降は各NoSQLの使い方についての説明が行われている。1冊の本で7つものデータベースソフトウェアを紹介しているだけあって、それぞれ使いかたの概要だけがかなりハイテンポで記述されている。それぞれのデータベースごとに、3日で学習できるような構成がとられている。あまり細かい説明はなく、自分で試すときにどのようにすれば良いかといった、いわばチュートリアル的な内容が並んでいる。手を動かしながら学習したい実践派の人々にオススメである。また、1冊で紹介できる内容としては濃密であり、「NoSQLはたくさんあるけどそれぞれをディープに勉強している暇はないが、どんなものがあるかを知りたい」という人には最適であると言える。従って、第2章「PostgreSQL」以外の部分は良い書籍であり、2章を読む前に感じた「わくわく感」をそのまま感じることができた。もし購入された際には2章をまったく読まないか、上記のような問題点があるということを念頭に読んで頂きたい。そうすれば本書はオススメの一冊である。

さいごに、NoSQLを選択する方々に向けて

本書を読むと「RDBMSではなくNoSQLを使ってみよう」という気にさせられるかも知れない。書籍の中では「ポリグロット永続化」というモデルが提唱されており、RDBMSに取って代わるだろうというような展望が掲げられている。だが、その意見を鵜呑みにするのは待って欲しい。原著者はリレーショナルモデルについて全く誤解している可能性があるからだ。

私自身、NoSQLの利用は今後増えていくと考えている。だが、それはRDBMSにとって代わるのではなく、RDBMSと併用することが多くなるだろうと考えだ。なぜなら、リレーショナルモデルは確固とした数学モデルに裏打ちされたものであり、レコード単位でデータを扱う以上、データの論理的整合性を保証しようと思うと、どうやっても逃れられることができないからである。

RDBMS抜きでやると、結局はアプリケーション側でリレーショナルモデルを実践する必要がある。それはとても壮大な車輪の再発明になるだろう。データの整合性を保つにはどうすれば良いか。定期的にチェックするべきか、それともアドホックにチェックするロジックを実装するべきだろうか。アドホックにやろうとするとパフォーマンスは大丈夫だろうか。特に構造化されていないデータの場合には、データの論理的整合性を確認するのは地獄である。

リレーショナルモデルはデータベースにおけるとても重要で便利なパーツである。それは「釘」のようなものだと言えるかもしれない。釘を使わずに木の家を建てるとどうなるだろうか。もちろんそのような家はとても危うく、ひとたびバランスを失うと全てが崩れ去ってしまうだろう。釘を使わなくても堅牢な家を建てられるけど、宮大工のような特殊な技能が必要になる。たぶんそれは釘を使うよりも難しい。

リレーショナルモデルもそれと全く同じで、リレーショナルモデルに頼らずにデータベースアプリケーションを構築することは可能だ。つまり「データの整合性が取れるようにプログラムを書く」ということだ。確かにそれは理屈の上では可能であるが、とても危険な行為である。「プログラムでデータの整合性を保証する」ということは、裏返すと「データの整合性はバグによって崩れ去ってしまう」ということだからだ。バグのないプログラムなど書けるだろうか？いや、書けるはずがない。リレーショナルモデルに頼らずにデータの論理的な整合性を保証しようという試みはとても危険な行為なのである。危険だということを分かって使うならいいが、そうでなければ大怪我をすることになるだろう。

本書ではデータの論理的な整合性についての考察は一切ない。（物理的なデータの整合性についての説明はある。CAP定理でいう結果整合性は物理的な整合性である。）原著者がリレーショナルモデルを理解していないか、あるいは意図的にそう書いたのかも知れない。決して「論理的な整合性について考える必要はない」などと思わないで頂きたい。堅牢なアプリケーションを構築する上で、それはとても重要なことだからだ。

もしあなたがまだRDBMSについて十分な知識を身に着けていないのなら、本書は手に取るべきではない。まずはRDBMSについて十分に学習するのが良いだろう。