マルチモデルデータベースが次のトレンド？

私はずっと「NoSQL」が嫌いでした。と言っても NoSQL データベースが嫌いだった訳ではなく、「NoSQL」という略語が嫌いだったのです。まずこれをどう読むのかが混乱の元です。「ノー SQL（＝ SQL ではない）」と読むのか、あるいは「ノットオンリー SQL（＝ SQL だけではない）」と読むのかでは、全く意味が違ってきます。前者では SQL が扱えず、後者では SQL も扱えるということになってしまいます。「ノー」のほうが「ノットオンリー」よりは楽なので、「ノー」という読み方の方が一般に使用されていますが、これでは、この新しい概念の説明は矛盾したものとなってしまっています。これは SQL は扱えません。いや、やっぱり扱えます！

個人的には、この混乱によって、このカテゴリーの一般的な意味自体がおかしくなってしまったと感じています。というのも、複数のデータモデルのみならず、さまざまな構造を持ち組織の戦略も加味された複数のスキーマを読み込むことができるデータベースが存在する、という前提が無視されてしまうからです。「NoSQL」という名前が付けられたことで、こういったことを実現可能なデータベースは、最新型の洒落た名前のデータストアなんかと一緒にされてその辺に打ち捨てられてしまいます。

MarkLogic が、この点において苦労してきたのは事実です。アナリストたちに認知される10年以上も前から、MarkLogic はメディア企業や国防/情報機関で広く使われてきているのですが、誤解もされてきました。「データの一貫性（トランザクション）は担保できないですよね？」「いいえ、できます」。「SQL は使えないですよね？」「いいえ、使えますよ」。

幸いなことに、今や新しい名称が登場してきました。「マルチモデル」です。これはあらゆる種類のデータを受け入れられるこのデータストアにとって、従来のものに比べてかなり正確な名称となります。遂にこのようなカテゴリーが出てきたのは喜ばしいことです。

私の同僚であるデーモン・フェルドマン（MarkLogic のソリューションディレクター）は、色々な「約束」が寄せ集められたようなアーキテクチャを扱わなければならないことがよくあります。しかしこのアーキテクチャでは、解決しなければならない問題を解決できません。「お客さんには『色々なデータタイプを読み込めるし、さまざまな場所に格納できる』と説明されます。確かにこれは実現可能です」「しかし、これら全体にパーシステンス（維持/永続性/一貫性）を持たせることが難しいのです」。

従来は「ポリグロット・パーシステンス（異なる種類のものを一貫性を持って扱うこと）」を実現するには、各データタイプに応じて個別の技術で扱う、という考え方が主流でした。しかし「ポリグロット」の本来の意味は「たくさんの言葉を話せる」ということであり、「多数のコンポーネントを統合できる」ことではありません。

それでは、どのような解決策があるのでしょうか？　デーモンは、複数のデータモデルをネイティブに格納するデータベースがその解決策となる、と言っています。データモデルの例としては「ドキュメントモデルがあります。これは主に JSON や XML として扱われるものです。また RDF（トリプル）モデルがあります。これはセマンティックで使われます。そしてグラフモデルがあります。これに加えてテキストも１つのモデルと言っていいでしょう。というのもインデックス付けや管理法方法が他とは大きく異なるからです。また通常はテキスト用に別個のシステムを利用することが多くなっています。このため私は、テキストモデルというものもあると考えています」。

デーモンは、他のデータベースをくっつけるだけのベンダーには注意すべきだ、と言っています。「異なる大量のデータベースを1つのシステムにまとめようとするプロジェクトを、これまでいくつも見てきました。これは『ポリグロット・パーシステンスモデル』というやり方です。」「ここで問題となるのは、こういったシステムに含まれるエンタープライズコンポーネントは、まとめて一緒に使うことが難しいということです。例えば、テキストやドキュメントへのクエリは同時にできるかもしれません。しかし、同時にすべてをバックアップしてから同時にすべてをリストアしたい場合、各システムのバックアップが5秒ずつ遅れることが考えられます。この場合、どれが同期していないのかを把握する必要があります」

マルチモデルデータベースは、タイプが異なるデータを同一システム内に格納できます。このシステムには、統一されたデータガバナンス、管理、アクセスが備わっています。また格納したものを検索する必要ありますが、複数の検索を組み合わせられることが重要です。つまり、大量の異なるデータモデルを扱い、インデックスを付けられるデータベースを利用することで、テキスト、SPARQL、XQuery などを組み合わせたクエリを実行できます（あらゆる検索対象をキーとして利用できます）。

アナリストたちも違いを確信してきています。「これはもはや『リレーショナル』対『非リレーショナル』の時代ではない。我々は今やマルチモデルデータベース時代に入っているのだ」

しかしマルチモデルデータベースの時代が既に始まっているとしても、表面的な宣伝文句から事実を区別するには、基本的な理解が必要です。12月初頭、オライリーメディアのライブ・ウェブキャストにデーモンが出演し、マルチモデルデータベースのエンジニアリングにおける2つの流れを取り上げました。大量のモデルを集約して扱えるシングルプラットフォームと、多くのシステムパッケージ製品を複雑に統合する方法です。もちろん、マルチモデルが常に最適な訳ではありません。デーモンは、この新しい素晴らしいデータベースをいつどこで使うのか、またそこで必要とされるスキルについて説明しました。

もっと知りたい方は以下をどうぞ。

「Building on Multi-Model Database（マルチモデルデータベースの構築）」 ：マルチモデルデータベースについて解説した、110ページの決定版書籍。マルチモデルデータベースの最適な使い方と、企業にとってのメリットが記載されています。

オペレーショナルデータハブ: マルチモデルエンジニアリングの二つの方法：デーモン・フェルドマンによる45分のウェビナーです。マルチモデルの種類とその特性、自社のインフラに実装するべきタイミングなどについて解説しています。

フランケンシュタイン（継ぎはぎ）の悪夢を退ける：複数データベース間での一貫性を実現する試みの実例（悪夢）と、それをどのようにして解決するに至ったのかを、デーモン・フェルドマンが説明します。