あれれ、SQL回帰？　複数のデータモデルに対応していく「NoSQLデータベース」の今：Database Watch（2017年6月版）（1/2 ページ）

SQLから離れて始まったはずのNoSQLデータベースですが……

　NoSQLデータベースに「あれ？　SQL回帰？」と思わず感じてしまった事柄が、最近続けて発表されました。今回はこの「NoSQLの今」を探りましょう。

　そもそも「NoSQL」は一般的に「Not Only SQL」の略とされ、基本はSQL（Procedure Language/Structured Query Language）“以外”でデータにアクセスするデータベースソフトウェアの一分類と定義されています。しかし近年では、SQLでアクセスできるNoSQLも増えてきています。知人のエンジニアはかつて、「“Not Only Relational”と命名した方がよかったかもよね」などと述べていましたが、確かに今、あらためて考えると言い得て妙です。

　経緯を少し振り返ってみましょう。データベースでは長らくRDB（リレーショナルデータベース）が普及していました。データのアクセス方法がSQLとして標準化されたこともRDBが定着した大きな要因です。各種のRDB製品はいずれもSQL標準に準拠しつつ、更新や検索の性能を高めたり、運用管理機能を充実させるなどの方法で使い勝手を高めたりして競い合っていました。

　しかし近年では、扱われるデータが多様化し、かつ、その量そのものも爆発的に増えてきていること、そして負荷分散管理の必要性も生じていることなど、これまでのRDBでは実現しにくい課題が幾つか浮かび上がってきました。この課題を解決するべく、RDBにおける表形式のデータモデルを“持たない”新しいデータベースが次々と登場しました。それらがNoSQLと総称されています。新しい概念は、「SQLではない（SQLを使わない）」というよりも「データモデル」でした。

　さて、NoSQLが「RDBのデータモデルではない」としても、2017年7月現在はいろいろな「データモデル」があります。例えばシンプルなKVS（キーバリューストア）型だと「Memcached」や「Redis」、JSON（JavaScript Object Notation）やXML（Extensible Markup Language）でよく使われるドキュメント指向型では「MongoDB」や「Couchbase」、列単位の集計や更新に強いカラム指向型では「BigTable」や「Cassandra」、SNSの相関関係などに適したグラフ型では「Neo4j」などがあります。

　もともとSQLはRDBのデータモデルを前提にしたデータ操作言語です。RDBのデータモデルを持たなければ、SQL以外で操作することになる、だから「NoSQL」となりました。当初はそれでよかったのですが、SQLはデータベース操作の標準として定着していただけに、「慣れた方法で操作したい」と考える開発者からの要望が多く挙がるようにもなりました。そのために、NoSQLで「SQLも使える」ものが増えてきました。

　この当初のNoSQLという表現は、まだ現状と懸け離れているわけではないと思います。しかし、状況は日々変わっています。これを端的に示している「RDBではないデータベース」で最近目立つキーワードが、「マルチモデル」です。

　この状況を後押ししているのは、言うまでもなく、ビッグデータやAI（Artificial Intelligence：人工知能）活用のトレンドです。「とにかくたくさん」の、「あらゆる種類」のデータを収集して分析することによって、新しい知見を発見したり、システムの自動学習に役立てたりします。データモデルはこれのみと限定するのではなく、何でも旺盛に取り入れるデータプラットフォームとして、「複数のデータモデルに対応する」＝JSONやXML、キーバリュー、グラフなど、NoSQLの多様なデータモデルに対応した「マルチモデル」であることが強みになってきているということになります。

　今回はこの「マルチモデル」を掲げた代表的なデータベースを2つ紹介します。MarkLogicの「MarkLogic 9」と、Microsoftの「Azure Cosmos DB」です。

エンタープライズニーズを満たすNoSQLデータプラットフォーム「MarkLogic」

MarkLogic CEOのゲイリー・ブルーム氏

　MarkLogicは、2017年6月1日に都内で行われたMarkLogic World Tokyo 2017で登壇した同社CEOのゲイリー・ブルーム氏によると、「企業向けNoSQLデータベース」という位置付けをアピールしていました。その特長は、「柔軟なデータモデル（マルチモデル）」「ユニバーサルインデックス」「企業向け」の3つです。

　まずMarkLogicは「スキーマレス（データベースの構造を定義しない）データベース」であることを特長としています。つまり、入力されたデータは隔てなく“そのまま”取り込みます。

　これはどういうことか、RDBと比較してみましょう。RDBであれば、事前にきちんとデータ構造を定義した上で格納しなければなりません。データ統合などで別のデータベースからデータを取り込むときには、データを変換する「ETL（Extract/Transform/Load）処理」が必要になります。また、取り込む元のデータベースで変更があったならば、ETL処理やインデックスの再作成などを行わなければなりません。

　しかしMarkLogicではその工程を必要とせず、「そのまま」突っ込めてしまいます。RDBで扱うような構造化データはもちろん、NoSQLに分類されるキーバリュー型、ドキュメント型、グラフ型、位置情報型など、構造化されていない複数のデータモデルにも柔軟に対応しています。

「MarkLogic」のWebサイト

　ユニバーサルインデックスとは、MarkLogicにおけるインデックスの呼称です。その名称の通り「（MarkLogicでの処理における）不変的なインデックス」のことです。読み込んだデータに対してユニバーサルインデックスを付けることで、不変的なデータへの問い合わせなどへ対応できるようにしています。

　これをどのように実現しているのでしょうか。技術的には、かつて検索エンジンで使われていたデータ処理技術が源流になっているそうです。開発のキーパーソンは、同社の創業者となるクリストファー・リンブラッド氏。リンブラッド氏はかつて、Infoseekが提供していた企業内イントラネットの高速検索を行うアプリケーション「Ultraseek Server」のアーキテクトでした。「検索エンジンの使い勝手を企業の情報システムで使えるようにする」がMarkLogicのそもそもの構想とのことで、2017年現在でも現役の開発者としてコーディングにいそしんでいるそうです。

　そしてMarkLogicは、セキュリティやコンプライアンスなどのエンタープライズレベルの需要を満たす「企業向け」であることも大きな強みに挙げています。企業のデータ基盤として使うからには、当然、データの信頼性を確保できなければなりません。MarkLogicはNoSQLデータベースながらも「100％のACID準拠」を掲げ、トランザクション処理の信頼性に必要であるAtomicity＝不可分性（原子性）、Consistency＝一貫性、Isolation＝独立性、Durability＝永続性を保持します。また、ロールベースのアクセス制御をするなど、当然ながらデータセキュリティも配慮されています。

　MarkLogicの得意な分野は、「データを統合していくようなシステム」への適用です。既存の多数のシステムに分散しているデータをMarkLogicデータベースに集約させて、データを一元的に取り扱えるようにしたいと考える企業に向けた新世代のデータ基盤としての需要が高まっているそうです。

　例えば米国のオバマケア（米国医療保障制度改革の通称）の象徴となる「HealthCare.gov」サイトでは、医療保険の加入審査に必要なデータ、保険事業会社のデータなど、あらゆるシステムからの膨大な量のデータをMarkLogicへ集約することで運用されています。他にも、文書検索とアラート通知のために米国の大手メディア企業 ダウ・ジョーンズが活用していたり、日本でも2016年から日産自動車が自動車部品管理のためのグローバル基盤として採用するべく、PoC（Proof of Concept：導入前実機検証）を進めていたりするそうです。

　何よりもMarkLogicの強みは、ユニバーサルインデックスではないでしょうか。全文検索をはるかに発展させたインデックスの仕組みです。「とにかくデータを取り込めばいい」とする特長は、これまでのRDBMSにおけるバージョンアップや移行、データ統合などのさまざまな課題をスッと解消できる、将来を見据えられるデータ基盤であると同社は述べています。