ここから本文です

あれれ、SQL回帰? 複数のデータモデルに対応していく「NoSQLデータベース」の今

7/13(木) 7:55配信

@IT

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

Azure Cosmos DBの主な特長

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

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

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

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

 ユニバーサルインデックスとは、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におけるバージョンアップや移行、データ統合などのさまざまな課題をスッと解消できる、将来を見据えられるデータ基盤であると同社は述べています。

●グローバル分散型でマルチモデルのデータベースサービス「Azure Cosmos DB」

 Microsoftは、2017年5月に開催された「Build 2017」で、新しいNoSQLデータベース「Azure Cosmos DB」を発表しました。同月、日本マイクロソフトが開催した「de:code 2017」では同社エバンジェリストの佐藤直生氏が登壇し、Azure Cosmos DBを「プラネットスケール(地球規模)のNoSQLサービス。高可用性、レイテンシ、スループット、データ一貫性、4つの包括的なSLA(Service Level Agreement:サービス品質保証)を備えた唯一のデータベースです」と説明していました。

 Azure Cosmos DBは、Microsoft Azure上でフルマネージド型のデータベースサービスとして提供されます。料金は他のサービスと同様に、使った分だけ支払うサブスクリプション型となります。

 Azure Cosmos DBはNoSQLデータベースとしては後発のように思えますが、実は歴史は意外と長いのです。2010年にMicrosoft社内で「Project Florence」として始まり、いったん「Azure DocumentDB」として提供されています。今回リリースされたAzure Cosmos DBは、Azure DocumentDBに機能を拡張した更新版という位置付けです。既存のAzure DocumentDBのユーザーは自動的にAzure Cosmos DBへと移行されるそうです。

 大きな特長は、地球規模と称されるように「グローバル規模で分散すること」と「マルチモデルであること」、そして「整合性レベルを選べること」です。

 まずは前者ですが、Azure Cosmos DBは「アプリケーションを世界展開する規模のサービス」を主なターゲットに据えています。昨今、Webサービスをグローバル展開する事業は珍しくありません。しかし、世界中にアプリケーションを展開するとなれば、データを分散管理しつつも“いかにデータの整合性を保つか”が重要になります。併せて、スループットを維持し、かつ常時稼働も条件になります。Azure Cosmos DBは、こうした課題を解決するために開発されました。

 Azure Cosmos DBは「ターンキー(導入後、すぐ使えるようにする)」でのグローバル分散を可能にします。複数のAzureリージョンにデータを自動的にレプリケートし、ストレージとスループットもそれぞれ個別でスケールできます。時間帯によって負荷の高いサーバが移っていくようなワークロードでも柔軟にスケールできるとMicrosoftは述べています。ここは、データベースサービスというよりは、パブリッククラウドとしてのMicrosoft Azureの性能の高さが大きく寄与しているといえるでしょう。

 それに加えて、「マルチモデル」と「マルチAPI(Application Programming Interface)」の特長も備えています。前述したMarkLogicと同様に、Azure Cosmos DBも複数のデータモデルに対応しています。2017年7月時点ではKVS型、ドキュメント型、グラフ型、列指向型の4つのデータモデルをネイティブでサポートしています。APIでアクセスするならば、「Table API(2017年7月現在はプレビュー版)」「MongoDB向けAPI」「SQL構文が使えるDocumentDB API」「Graph API(Gremlin、2017年7月現在はプレビュー版)」が使えます。対応するデータモデルは今後さらに増える見込みです。

 Azure Cosmos DBはまた、「整合性のレベルを選べる」ようにもなっています。データを分散管理すると、データの整合性が課題になってくるのは皆さんも承知していると思います。ただし昨今、パフォーマンスなどが多少犠牲になるとしても「とにかく整合性を完全に確保する」のか、それともパフォーマンスを重視して「結果的に合っていればいい」のか、製品、業務、サービス、コストなどによってデータ管理レベルやポリシーが異なるシステムも増えています。Azure Cosmos DBではこのニーズに沿い、「全5段階」で整合性のレベルを選べるようになっています。アプリケーションの要件に合わせて柔軟に選択できるということですね。

 以上のように、企業や開発者のニーズに沿い、マルチモデル対応のNoSQLデータベースが普及しつつあります。ただし同じマルチモデル対応のNoSQLデータベースでも、今回紹介した2つは対照的といえます。雑な言い方ながら違いを強調するならば、「ぎゅっと集めるMarkLogic」と「どばっと広げるAzure Cosmos DB」という感じでしょうか。

 いずれにしても将来を見据えた統合データ基盤として、「多様なデータモデルに対応できる」仕様は今後重視されていきそうです。

最終更新:7/13(木) 7:55
@IT