MEANスタックは破壊的か

最近、MEANがイイという話をチラホラと耳にする。先日も次の記事がはてブで話題になっていた。

MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて - albatrosary's blog

この記事の冒頭では、MEANはLAMPに変わる技術として紹介されているが、果たしてそれは正しいのだろうか。（この記事では、LAMPを例にとりつつJavaがどうのという記述があるので、恐らくはLAMPではなく既存のリレーショナルデータベースを用いたアーキテクチャ一般について述べたいのではないかと思う。）MEANについて少し思うところがあるので、今日はMEANの可能性について書き綴っておこうと思う。ただし、私自身MEANスタックと呼ばれるシロモノは使ったことがなく、構造を理解した上でのデータベース技術者としての意見であることを断っておきたい。

JSONはデータモデルではない

上記の記事で一点気になったのは、JSONがあたかもデータモデルであるかのように書いている点だ。これは多くの人が誤解しているかも知れないが、JSONはデータモデルでもなんでもない。データモデルとは、論理的なデータ構造がどうなっているか、どのような手法でアクセスあるいは加工がなされるかということを定義したものだ。JavaScriptでそのまま読み込める、汎用言語であるJavaScriptの文法を使って処理できるというのはひとつの特性ではあるものの、論理的なデータ構造を表現しているとは言いがたい。JavaScriptで操作できるというのはいわば何でもアリだ。何か特別な振る舞いについて規定しているわけではない。すなわち、データモデルでも何でもない。

ではJSONは何かというと、データの記述法の一つであると言える。あるいはフォーマットと言っても差し支えないだろう。また、MongoDBがドキュメント型データベースと呼ばれているように、JSONの実体はドキュメントであると見ることもできる。ドキュメントはそれぞれのノードが任意の子ノードを持つというツリー構造になっている。つまりJSONは本質的にはツリーなのだ。（様々な付随する情報が付け加えられた）ツリーを文字列として表現するための記述法のひとつであると言えるのである。ツリーを表現する方法の一つという意味では、XMLやYAMLと本質的に何ら変わりはない。JSONが独自のデータモデルを持っているわけではないのである。そんなわけでフォーマットとデータモデルを混同するのは止したほうが良いだろう。

JSONはツリーなので、ドキュメント型データベースとは、小規模なツリーが多数並んだような構造になっているものであると言える。生垣型の構造と言っても良いかも知れない。

破壊的な要素はある

本エントリのテーマは、MEANが流行るかどうか、つまりイノベーションのジレンマでいうところの破壊的な技術であるかということだ。確かにMEANは既存のスタックとは性質が異なる。とは言え、ウェブアプリやスマホアプリを作ることができるという点では同じである。

流行るかどうかにおける最大のポイントは、如何に手軽に素早くアプリを開発できるかという点であろう。イノベーションのジレンマとは、「劣った技術が優れた技術を駆逐していく」というものだ。MEAN（のようなJSONをベースにしたスタック）は、主にデータの保守性では極めて劣っていると言わざるを得ない。劣っているからこそ、破壊的な要素があるといえよう。

破壊的な技術が成功するかどうかは、既存の技術にはない圧倒的な手軽さや、圧倒的な安さが決めてとなる。MEANスタックには果たしてそれあがるだろうか。物凄く手軽に使い捨てのウェブアプリをポンポンと開発できると言うのなら、MEANには大いなる勝機があるだろう。アプリ開発の手間が半分になるというのなら、大規模に向かないとはいえ、MEANに飛びつく人は多いはずだ。

ただ、全ての破壊的な技術が成功するわけではない。潜在的に破壊的な技術、つまり既存のものより劣った未完成の技術は、雨後の筍のように次から次へと生み出されている。もちろんそれら全てが成功するわけではない。成功するものは、破壊的な技術の中でもほんのひと握りのものである。MEANには破壊的な要素はあるが、成功するかどうかはこれからの成り行き次第だと言えよう。

課題は複雑さへの対処

破壊的なイノベーションは劣った技術が優れた技術を駆逐して行く。かつて（容量の劣る）3.5インチHDDが5インチHDDを駆逐したように。

果たしてMEANはLAMPスタックを駆逐するほどの存在たるだろうか。その点には、私は懐疑的である。

リレーショナルデータベースは意味もなく、デファクトスタンダードだからといった下らない理由で普及しているわけではない。そこには、大規模になったデータの複雑さに対して如何に立ち向かうかという課題への解があるという理由がある。データベースにとって、データの整合性は命綱である。クエリの結果、不正確なデータしか得られないようなデータベースは価値がないからだ。複雑さが増せばその分データの整合性を保つのは難しくなる。リレーショナルデータベースには、その課題に対する解が用意されている。それが正規化だ。

ドキュメント型データベースには、そのようなものはない。全てはアプリケーションのコード次第で決まる。もしアプリケーションにバグがあれば、データの整合性は直ちに破綻してしまうだろう。そのような状況では、アプリケーションをより複雑にすることはできないのである。

地球にはかつて単細胞生物しか居なかった。単細胞生物が規模を大きくするには、酸素の利用が不可欠であり、酸素を利用するには酸素からDNAを守る核の発達が必要だった。多細胞生物になっても、当初は浸透圧によって酸素を運搬していたため、大きくなるには限界があった。だが、循環器というアーキテクチャを得て、個体のサイズを大きくすることに成功した。

このように、システムがより複雑に進化するには、それを支えるアーキテクチャの存在が不可欠である。残念ながら、MEANスタックにはそれが無いように見える。

MEANスタックはおそらくスキーマが極めて単純な小規模なものであれば有用だろうが、スキーマが少しでも複雑になると、とたんに開発効率が悪化するだろう。複雑さの壁を打ち破ることができない限り、規模の大きなアプリケーションを開発するには向かないものと思われる。この制約がある限り、LAMPに変わる技術となることはあり得ないし、ましてLAMPを駆逐するようなこともないだろう。