リレーショナルの視点から見たMarkLogic：パート1

技術環境におけるMarkLogic

本記事は、リレーショナルデータベースのバックグラウンドを持つユーザーに向けたブログシリーズの第1回です。MarkLogicのデータ統合およびアクセス処理はどのように違うのかを理解するのに役立ちます。

要約：リレーショナルデータベースの課題に対処するために、過去20年間、多くの技術が導入されてきました。MarkLogicは真のマルチモデルデータベースとして、データ統合の複雑性と拡張性に関する問題を解決し、リレーショナルデータベースと同等のデータ管理機能を提供するだけでなく、検索、アラート、地理情報を含む統合技術スタックによってさらなる機能を実現します。

---

進化するデータ環境

1970年代後半または1980年代初頭から2000年前後にかけて、リレーショナルがデータベースの世界を支配しました。オブジェクト指向データベースや階層型データベース時代の遺物もいくつか見られましたが、その数は少なくなっていました。
2000年頃、リレーショナルデータベースの支配に亀裂が生じ始めます。拡張が不可能なこと、複数のデータソースおよび複雑なデータの統合が難しいことが、その原因の一端でした。拡張性が損なわれた理由は、リレーショナルに必要とされる結合作業が大規模かつ高価であるためです。複雑なエンティティをストレージのために行と列の長方形に分割しなければならず、分割したものをまとめるには結合が必要でした。複雑性が増した理由は2つあり、基盤となるデータが複雑化したことと、重複した多数のデータセットを企業組織が1つのまとまったデータセットに統合したことです。
こうした状況に対応するため、データ技術に大きな動きが起こりました。NoSQLデータベースと呼ばれるさまざまな種類の新技術が広く使用されるようになったのです。これには、ドキュメント、検索、グラフデータベースが含まれます。ユーザーへのプッシュ通知とクエリ実行の両方が可能な、複合イベント処理（CEP）に基づいたアプローチがニッチ市場も獲得しました。リレーショナルデータベースの長年の課題を解決するこれらの技術は市場に定着しました。
Hadoopも、極めて大規模な分散データのアクセスと処理を提供する原動力となりました。
しかし、どの新技術も新しい機能は提供するものの、リレーショナルシステムの重要な中核技術を再現することはできませんでした。このため、今日まで、主要なデータベース技術としてリレーショナルが存続しているのです。
根本的な課題は、新技術のほとんどが、エンティティタイプ内でフィルタリングしながら異なるデータ型を組み合わせた構造化クエリの実行に問題を抱えていたことです。これはリレーショナルデータベースの一番の課題となる点です。

ドキュメントデータベース

ドキュメントデータベース はデータ型内でのデータのフィルタリングに優れています。そのため、データの複雑性と多様なデータセットの統合に関わる問題の解決に役立ちます。
ただし、ドキュメントデータベースは、異なるエンティティタイプからデータをリンクすること（顧客の注文すべてをまとめたクエリなど）が不得意です。

セマンティックデータベース

セマンティック セマンティックデータベースは関係性の処理に優れているため、異種のデータ型を結合するクエリを簡単に実行できます。
ただし、純粋なセマンティックソリューションは、リレーショナルデータベースよりも拡張性の点で劣ります。また、データの各行の各フィールドをそれ自身のトリプルに変換しないと使用できないことから、極めて大きな複雑性の課題も抱えています。単一の行またはドキュメントのデータを複数のトリプルから集める必要があるため、情報をまとめる処理が複雑になります。

検索とCEP

検索と CEP は、従来のリレーショナルデータベースとは根本的に異なる有用な機能を実現しました。ただ、リレーショナルで実行が難しかったいくつかのことは可能になったものの、決してその代わりになるものではありませんでした。検索を使用することで、基盤となるデータ構造を理解する必要もなく、構造化データも一切なしで、データのアクセスと検索が可能になりました。CEPでは、ユーザーがデータを要求しなくても適切なタイミングでデータがユーザーにプッシュされます。

Hadoop

Hadoopは高い拡張性を実現しましたが、基盤となるデータベース技術を補完するため、アプリケーション開発者側で別途機能を追加する必要があります。Hadoopの台頭により、「スキーマ非依存」および「スキーマレス」が業界用語として一般化しました。拡張性を最大化するメリットを優先するあまり、データ・ディクショナリーによるメリットが失われたのです。

MarkLogic：真のマルチモデル

MarkLogicでは、SQLを含め、ここまで説明してきた技術のすべてが1つの統合データベースに組み込まれています。これを実現したことで、MarkLogicはおそらく唯一の真の 「マルチモデル」データベースとなっています。他社から提供されている「マルチプロダクト」では、さまざまなデータ型が別々のデータベースに格納されているため、ほとんどの場合、開発者が個別に統合する必要があります。複数の技術を1つの統合された環境に組み込んだことにより、MarkLogicは、リレーショナルデータベースの検索とクエリの機能を管理および向上しながらも、リレーショナルが抱える複雑性と拡張性の課題を解決できました。
他のNoSQL製品では、このような環境の実現は困難です。これは、多くのNoSQL製品がオープンソースを基盤として構築されているため、技術タイプごとに開発作業が異なることが理由です。単一のアプリケーションで複数の技術を使用するには、複数のデータベースを保持し、異なる技術を統合する必要があります。これにより、データの信頼性、災害復旧、開発のしやすさに関する課題が生まれます。
MarkLogicではデータベースは1つです。単一のクエリに、SQL、SPARQL, 構造化ドキュメントフィルタリング、検索を含めることができます。MarkLogicのクエリ計画者は、クエリを構文解析して、実装する方法を決定します。ドキュメントが読み込み、変更、または削除された場合に通知を送信するようにアラートを定義できます。
MarkLogicでは、ドキュメントとセマンティックを統合することで、基盤となるスキーマをドキュメントが完全に共有していない場合でもエンティティタイプ内でのフィルタリングが可能です。セマンティックを使用して異なる種類のドキュメントを結合することにより、リレーショナルの性能が加わります。
この組み合わせにより、MarkLogicではリレーショナルデータベースと同等の機能を使用でき、複雑性と拡張性の課題を解決できます。検索、アラート、地理情報により、さらなる改良が可能です。

すべてをモデル化するか否か

大規模で複雑なリレーショナルシステムの開発が難しい理由は、 データモデリングに対するウォーターフォールモデルにあります。ウォーターフォールモデルでは、データを読み込む前にスキーマを定義する必要があります。このため、開発を実施する前に、数か月間または数年間にも及ぶモデリングが必要になる可能性があります。データモデルが複雑に重なり合う今日、開発開始前のデータベースには、重複したデータソースのすべてを組み合わせた正式な完全なモデルは必須ではないと認識することが重要です。
MarkLogicでは、すべてのデータをそのまま読み込んで、最初の成果物の目標を達成するために必要なモデリングと構造変更だけを行います。
最初の成果物が完成したら、これを基盤として構築を続けて、次の成果物に必要なモデリングとETLを行います。アプリケーションごとのデータサイロを作っているのではありません。よりリッチで統合されたデータ環境を徐々に築いているのです。
この方法によって、中心となるエンタープライズデータリポジトリまたはハブを構築しながら、迅速にアプリケーションを提供することができます。
このシリーズの次の記事 「データモデリング – リレーショナルからMarkLogicへ」では、モデリングに関する疑問をさらに深く検討していきます。

マルチモデルの利点

ドキュメント技術によって、MarkLogicの高性能なクエリが実現されています。また、複雑なデータの処理と、重複したデータセットの統合が容易です。
グラフ技術により、リレーショナルな結合を上回る性能で異種データセットを統合できます。
MarkLogicは、統合された技術スタックによってリレーショナルデータベースの制約を克服しただけでなく、より優れた性能を提供します。
MarkLogicは、リレーショナルを超える次のステップなのです。

---

詳細はこちら

• リレーショナルデータベースの「マトリックスから脱出する方法」をご覧ください。
• 本シリーズの他の記事はこちらです。
  • パート2 – データモデリング – リレーショナルからMarkLogicへ
  • パート 3 – リレーショナルからMarkLogicへの移行
  • パート 4 – データ活用の最適なパートナー