マルチモデルが次世代のデータベース技術？

データベースプラットフォームは、情報を捉えて格納し、後で利用できるようにするものです。

データベース技術は、データタイプごとに進化してきました。表（テーブル）データを管理するために、リレーショナルモデルが生まれました。地図には、地理情報モデルが必要でした。階層を表すにはグラフ的な表現が求められました。ドキュメントには、ドキュメントモデルがあります。他にもいろいろあります。

アプリケーションを作る場合、必要とされるデータタイプに応じて構築します。

クラウドネイティブのモダンなアプリケーションでは、さまざまなマイクロサービスを組み合わせて使用しています。各マイクロサービスにはデータがカプセル化されており、必要に応じて異なるデータタイプやデータベースが使用されています。開発者は、必要とされるシンプルなタイプに基づくデータベース技術を選択します。

このようにして構築されたアプリケーションは、「分割して統治せよ」的なアプローチを採用することで開発期間が短縮され保守がシンプルになります。1つのマイクロサービスを変更しても他に影響がありません。しかしながら、このやり方にも問題はあります。

まず運用上の観点から見ると、多くのデータ管理技術を寄せ集めたために不確定要素が多く、かなり複雑です。このため、旧来のアプリケーション状況の問題がさほど改善されません。

一方、このような「ポリグロットパーシステンス」アプリケーションは、業務部門を超えてデータを把握したいビジネスユーザーにとっても好ましくありません。というのもソースデータを各データストアから個別に抽出/整理/ハーモナイズしなければならないため、旧来のレガシーアプリケーションと似たような問題が発生するからです。

こういった問題のいずれかの（あるいは場合によっては両方の）解決策として、マルチモデルデータベースが登場しています。

マルチモデルデータベースの登場：データの格納手段として

マルチモデルデータベースでは、複数のデータタイプを1つのインスタンスだけで格納できます。これにより、たくさんのものが使用されていることに起因する、複雑な運用を回避できます。

マルチモデルでない場合、個々の特化型データストアごとに、事前確認/設定/モニタリング/セキュリティ設定/最適化が必要です。最初はシンプルに見えても、数が増えてくるとすぐに大変になります。

こういったことを考えると、マルチモデルが好ましいでしょう。というのもデータタイプが複数あっても、運用チームはたった1つのデータストアを使うだけで良いからです。開発者は、依然としてデータをマイクロサービス内にカプセル化できます。

つまり他の条件がすべて同じだとしたら、こちらの方が良いでしょう。

しかし、このアプローチはビジネスユーザーにとってはどうなのでしょうか。複数ソース由来の複数のデータタイプを関連付けることは、その格納場所がマルチモデルデータベースであろうとなかろうと、難しいことは間違いないでしょう。

「ビジネスユーザーが何を求めているのか」、また「このニーズをマルチモデルデータベースでどう解決するのか」をちゃんと理解するためには、いったん視点を変えて全体を確認してみる必要があります。

データをどのように表現したいのか

例えば、自分の家族について調べているとします。ここで、今わかっている親戚1人1人の情報が載っているインデックスカードを作ったとします。このカードの利用方法はさまざまあるでしょう。

家系図として見たい場合は、これらをグラフとして整理できます。あるいは名前と住所のリストを作成できます。これはリレーショナルデータベース的なやり方です。また各人の写真やビデオを含めたり、新しいビデオを作りたくなるかもしれません。

地図上に住所をマッピングして、皆がどこに住んでいるのかを確認することもできます。これは地理情報的な表現と言えます。またインデックスカードのそれぞれに小さなログを記録しておくこともできます。例えば、作成日/最終更新日/作成者などを記録しておくことで、この情報の出自が把握できます。あるいは、念のために旧バージョンを残しておくこともあるでしょう。

こういった各カード上の情報は、必要に応じてさまざまな方法で関連付けることができます。ここでそれぞれの場合ごとに、異なるスキーマが使われるでしょう。「スキーマ」は、生データの表現方法を定義するものです。今回の例で言えば、電話番号、住所、地図上の位置などの表現方法を決めます。これは大量の1/0（イチゼロ）の情報を人間が分かるようにする際の「レンズ」（見方）を定義しているとも言えます。

ここで、特定のデータだけを扱う場合、あるいは新しい関連付けのたびに、こういったインデックスカードすべてを複製しなければならない事態は避けたいでしょう。

例えば家系図を見たい場合、あるいは名前と住所のリストを作成する場合に、これらすべてのカードの複製を別途作成しなければならないとしたら面倒です。これは写真および動画を扱う場合や地図上へのマッピングの場合でも同じです。あるいは、関連付けが変わるたびに、全部をコピーしなければならないという状況も考えられます。

これは非効率的だと思いませんか。そして実際のところ、このやり方は非効率的です。そんなことをすれば、個々の活用シナリオやユーザーごとに、状況が複雑になっていきます。しかし企業のITにはこれと同じことが起こっています。みんな自分なりの方法でデータを見たいと思っており、そのたびごとにデータを複製しているのです。

この場合、全員が共通の「ゴールデンコピー」だけを扱うようにできたら、素晴らしくないでしょうか。またこれを、それぞれが使いたいように使えるといいでしょう。

マルチモデルデータベースの登場：データの提供手段として

先ほどの家系図の例をさらに見ていきましょう。例えば、数千万人のユーザーが自分の家系を調べられるwebサイトがあるとします。この場合、必要な情報は大量になります。

それではここで、自分がこのアプリケーションアーキテクチャの担当になったと考えてみてください。

この場合、あらゆる形式のデータの読み込み、あらゆる形式での提供、個々の利用者による情報の関連付けが求められます。

ユーザーごとに、データをどう表示したいのか、関連付けたいのか（例えば養子は含むかどうかなど）は違っています。

このようなデータフローのパターン（データソース/データタイプ/ユーザー/レンズがすべて複数存在する）は、何ら珍しいものではありません。ここにおいて、マルチモデルデータベースは必要とされるアジリティだけでなく、しっかりとしたプラットフォームも提供できる可能性があります。

さまざまな違い

面白いことに、すべてのデータベース会社が「マルチモデルでデータを効率的に格納できる」とうたっていますが、実はデータを効率的に提供できない製品も存在します。この「違い」は重要です。

ここで私は、特にオラクルのデータベースだけを取り上げているわけではありません。他の多くのものもだいたい似たようなものです。オラクルは複数のデータタイプを極めて効果的に格納できるので、「マルチモデル」と呼ぶことができます。しかしこの同じデータをビジネスユーザーにアジャイルかつ柔軟に提供できるかというと、それほど上手くいきません。特に、複数のデータタイプ間の関係性を見たいと言われても、上手くいかないのです。

公正を期して言うと、格納は得意だけど提供は苦手なマルチモデルデータベースは、ある特定の分離されたアプリケーションには向いている可能性があります。対象データのビジネス上の活用方法が限定的ならば、それはそれでいいでしょう。

しかし「あらゆるものは変化する」のではないでしょうか。また、あらゆるデータは全く別の用途でも役立つ可能性があります。例えば、当初誰もメールやメッセージが重要だとは考えていなかったのに、ある時点からそれらが必要になることもありえます。アプリケーションアーキテクチャは、それを作った人よりも寿命が長いことを考えると、こういった変化も考慮しておく必要があります。

自分に合っているのはどれか

開発者たちに好かれるマルチモデルデータベースのカテゴリがあります。開発者は、やらなければならないことを早く終わらせたいですし、できれば今後の作業でも使えるツールを使いたいでしょう。新しいアプリケーションを短期間で開発できることが喜ばれることは、いつだって同じです。

一方、別のカテゴリのマルチモデルデータベースとして、開発者にとってはそれほど魅力的ではないかもしれないけれど、運用チームには好かれるものがあります。運用チームは、シンプルでより優れていて管理が簡単なものを求めます。

さらに、3つめのカテゴリとして（他よりも含まれるものは少ないですが）、「三方よし」と呼べるものもあります。つまり、ビジネスユーザーはデータを好きなときに入手でき、開発者はシンプルに開発でき、運用チームも運用対象がシンプルになるものです。

複数の業務部門を相手にしている場合（あるいは近い将来そうなることが予想される場合）、この3つめのものがベストでしょう。

ビジネスユーザーに彼らが求めているものを与えることができれば、通常それに伴っていろいろ素晴らしいことが起こります。例えば新しい/質が高い製品やサービスが産まれるだけでなく、顧客との関係が改善され、リスクが削減されたりするでしょう。

私たちは、MarkLogicを使って複雑なデータで何ができるかをぜひ皆さんにもご紹介したいと思っています。家系図webサイトだけでなく、興味深いものがさまざまあるのですから。