MarkLogic と Oracle との比較
概要
Oracle データベースは史上最も成功しているソフトウェア製品の1つです。この40年で、Oracle データベースはデータの格納/管理の市場における主要技術へと成長しました。また RDBMS および SQL は今やあらゆる大企業に定着しています。MarkLogic などの代替製品は Oracle よりも新しく、データ管理の新しい課題、特にデータ統合のニーズに対応するために開発されました。
今日の組織は、80年代や90年代には見られなかった新しい課題に直面しています。データは大規模化、高速化、多様化が進み、絶えず変化しています。組織は、少数のシステムではなく、数百のシステムでペタバイト単位のデータを扱うようになりました。また、ビジネスニーズはかつてないスピードで変化し、規制要件も以前にも増して厳しくなっています。このため、進化し続けるビジネスニーズに迅速に対応するために、データの管理方法を見直す必要があります。
- 組織は、データ統合のアジリティ、情報の全体像の把握、耐久性のあるデータ資産の迅速な提供を必要としています。データの統合を数か月、数年も待つことはできません。
- 組織はコストを削減する必要があります。これには、新しいシステムやアプリケーションの開発期間やインフラ保守時間の短縮も含まれます。クラウドに移行する組織は、クラウドのコストを制御可能にしておかなければなりません。
- 組織は、より優れたデータ共有のためにセキュリティとガバナンスを改善する必要があります。分断されたデータサイロの継ぎはぎや、シャドー IT に時間を費やすことはできません。統合ライフサイクル全体において、プロアクティブなデータ管理が必要です。
MarkLogic は、上記すべてにおいて Oracle よりも明らかに優れています。MarkLogic は、卓越したアジリティによりデータ統合を低リスクで実現します。クラウドのコストは極めて小さく、予測可能です。データセキュリティとデータガバナンスを犠牲にすることなく、新しいアプリケーションの提供時間を短縮できます。
この比較では、Oracle データベースと MarkLogic データベースの根本的な違いを確認し、MarkLogic データハブサービスと Oracle のクラウド製品スイートを比べていきます。主な違いを以下にまとめました。
- Oracle と MarkLogic では、データモデルが根本的に異なります (リレーショナル vs マルチモデル)。
- Oracle と MarkLogic では、インデックスとデータアクセスのアプローチが根本的に異なります (Oracle はリレーショナルインデックスと SQL、MarkLogic はユニバーサル/マルチモデルインデックスと検索ドリブンのアプローチ)。
- Oracle と MarkLogic では、拡張方法が大きく異なります (Oracle はスケールアップシステム、MarkLogic は分散型のスケールアウトシステム)。
- Oracle と MarkLogic では、クラウドでのデータ統合のアプローチがまったく異なります (Oracle は大量の保守作業が必要な従来のリレーショナル製品スイート、MarkLogic はチューニングと保守がほぼ不要の一元化されたアジャイルアプローチ)。
Oracle とは
Oracle は世界のソフトウェア企業上位10社の一角を占めており、最も広く採用されているリレーショナルデータベースを提供しています。Oracle は長年、Oracle データベース (とその派生物) のライセンスを収益の大きな柱にしています。ここ数年は、Oracle Cloud の構築に多額の投資を行っています (Oracle Cloud は、120を超えるさまざまな製品を SAAS、PAAS、IAAS の形態で提供するクラウドサービスです)。
Oracle リレーショナルデータベースは1979年に初めてリリースされました。このソフトウェアの最新リリースは Oracle Database 19c (Oracle 12c および 18c の長期サポートリリース) です。この中核製品にはさまざまなバリエーションがあります。Oracle の製品スイートには、異なる作業内容 (分析、トランザクション) を対象とした製品、エンジニアドシステム (ハードウェア/ソフトウェアを組み合わせたアプライアンス)、フルマネージドクラウドサービスが含まれます。
Oracle の主要製品ライン
- Oracle Database 19c – 2019年にリリースされた Oracle 19c はオリジナルの Oracle リレーショナルデータベースの最新バージョンで、オンプレミス環境向けのフラッグシップ製品です。Oracle は、バージョン19c を、Oracle 12c ファミリー製品 (Oracle 18c を含む) の最終リリースとして、長期サポートリリースすなわち「ターミナルパッチ」バージョンと呼んでいます。これは、Oracle Exadata を使用してエンジニアドシステムとして実行することも可能です。
- Oracle Autonomous Database – 2018年に初めてリリースされた、Oracle のクラウドサービスです。Oracle データベース上で実行されますが、別個の製品ファミリーとして構築および販売されています。ユーザーは、データ分析向けの Oracle Autonomous Data Warehouse と、混在ワークロード処理向けの Oracle Autonomous Transaction Processing の2つのオプションのいずれかを選択します。
その他の Oracle データベース製品 (ソフトウェアおよびクラウド)
- Oracle NoSQL Database – キー/バリューストア (主キーのみに対してクエリを実行するよう設計された2カラム型リレーショナルデータベース) で、2018年に JSON のネイティブサポートが追加されました。Redis などのオープンソースデータベースは、これと類似した機能および同じデータモデルを提供しています。
- Oracle NoSQL Database Cloud Service – 上記のオンプレミス版と類似した機能を備えたフルマネージドサービスです。2019年3月に提供が開始されました。
- Oracle Berkeley DB – XQuery による XML ドキュメントの格納およびクエリができる Oracle Berkeley DB XML が含まれています。Sleepycat の買収により Oracle 製品となりましたが、最終更新は2017年です。ユーザー数は小規模です。クラウドサービス版は提供されていません。
- Oracle XML DB (クラウドサービス機能) – 2019年5月に追加された XML ストレージおよびクエリ。多くの機能は使用できません。最新情報については、Oracle のドキュメントを参照してください。
- Oracle Spatial and Graph – 19c のオプションで、RDF トリプルの格納とナレッジグラフ構築の機能が含まれています。RDF トリプルはリレーショナルテーブルに格納されます。
- Oracle Spatial and Graph (クラウドサービス機能) – 段階的に機能が追加されてきています。最新情報については、Oracle のドキュメントを参照してください。
- Oracle Text – 19c のオプションで、全文インデックスを構築し、標準 SQL で検索および分析する機能が含まれています。
- Oracle Text (クラウドサービス機能) – 2019年5月に追加された全文検索です。従来の機能の多くは使用できません。最新情報については、Oracle のドキュメントを参照してください。
- Oracle TimesTen In-Memory Database – Redis、SAP HANA、MemSQL に似た Oracle のインメモリリレーショナルデータベースです。インメモリで実行することで、このデータベースは優れたキャッシュレイヤーとして機能します。Exalytics というエンジニアドシステムの形態でも販売されています。
- MySQL RDBMS – コミュニティ版とエンタープライズ版が提供されています。Oracle が2010年に Sun Microsystems を買収した際に Oracle 製品ラインに加わりました。
- Oracle Big Data Appliances および Oracle Big Data Connectors – Oracle は、Oracle の資産と Hadoop などのツールとの統合を希望する顧客向けに複数の製品を販売しています。これらは、Oracle に直接格納できないデータへの接続とアクセスを可能にします。
Oracle のその他のデータ統合製品
- Oracle Fusion Middleware – ESB を使用したオンプレミスの SOA 統合用ソフトウェアです。買収によって獲得した製品で主に構成されています。
- Oracle Golden Gate – 変更データのキャプチャ、配布、変換、提供のためのソフトウェアです。業務システムから分析システムへのリアルタイムのデータフローによく使用されます。クラウドサービスとしても提供されています。
- Oracle Data Integrator Cloud Service – Oracle の新しいクラウド製品スイートに含まれています。従来の ETL 作業をクラウド環境で実行するソフトウェアです。クラウドサービスとしても提供されています。
- その他の Big Data Cloud Service – Hadoop や Spark を活用したデータ分析用のクラウドサービスです。
MarkLogic とは
MarkLogic データハブサービスは MarkLogic のフラッグシップ製品です。アジャイルなデータ統合およびデータ管理用のフルマネージドのクラウドデータハブです。MarkLogic サーバーをベースに構築されており、MarkLogic サーバーと全く同じマルチモデル、セキュリティ、およびスケールアウト機能を備えています。
MarkLogic サーバーは、現代的な NoSQL と信頼性の高いエンタープライズ機能を備えたマルチモデルデータベースです。MarkLogic データハブサービスの一部として導入することも、任意の環境 (オンプレミス、クラウド、ハイブリッド) に単独で導入することもできます。
MarkLogic は、エコシステム用の関連ツールとコネクタも開発しています。さまざまな API やコネクタが提供されています。
MarkLogic と Oracle の違い
MarkLogic と Oracle は2つの方法で比較できます。
- MarkLogic サーバーと Oracle データベースの比較 — 主にデータモデルに注目した比較です。MarkLogic はマルチモデルアプローチで、Oracle はリレーショナルアプローチです。簡単に言うと、Oracle は素晴らしいリレーショナルデータベースを提供しており、リレーショナルデータベースを必要とし、Oracle エコシステムにすでに参加している組織にとっては、よい選択肢と言えます。しかし、分断されたデータを統合するための柔軟性を求める組織にとっては、MarkLogic のマルチモデルアプローチの方が明らかに優れています。この点については、以下で詳しく説明します (Oracle はマルチモデルであるとする最近の主張が説得力に欠ける理由も含めて)。
- Oracle の「データハブ」構築用クラウドサービススイートと MarkLogic データハブサービスの比較 — クラウド上でデータ統合を行う際、MarkLogic データハブサービスと同様の機能を揃えるためには、Oracle Autonomous Database と他のツールを組み合わせる必要があります。例えば、Oracle Data Integrator Cloud Service、Oracle GoldenGate Cloud Service、Oracle NoSQL Database Cloud Service などのサービスが必要です。また、どの環境であっても、マルチモデルデータベースにはないリレーショナルデータベース固有の根本的な問題が発生します。
- Oracle には2017年に提供を開始した「データハブサービス」製品がありましたが、現在は宣伝されていません。
- MarkLogic データハブはオンプレミスでも実行できますが、その場合も比較の結果はほぼ同じです。オンプレミスの場合も、MarkLogic データハブと同様の機能を揃えるには、Oracle NoSQL Database、Berkeley XML DB、Oracle Spatial and Graph、GoldenGate などの ETL ツール、その他のビッグデータツールなど、大規模な Oracle 製品スイートが必要です。
MarkLogic と Oracle データベースの比較
MarkLogic サーバーは、業界初の現代的なマルチモデルデータベースです。MarkLogic には、データのモデリング方法が複数あり (ドキュメント、グラフ、リレーショナルなど)、同一エンティティに関するデータも複数の方法でモデリング可能です。MarkLogic では、統合された単一のバックエンドを使用して、複数のスキーマを持つデータを同時に同一のデータベースに格納します。
わずか数年前でも「マルチモデル」という言葉は比較的新しく、それが何か、なぜ必要なのかを説明するのに、かなりの労力が必要でした。今では状況が変わり、マルチモデルデータベースは最新のデータアーキテクチャの一部として利用されるべきだと広く認識されています。
MarkLogic が提供するマルチモデルの利点を詳しく説明したリソースを以下に挙げます。
MarkLogic のマルチモデルのメリットを以下にまとめます。
- 絶えず変化するデータおよびスキーマを扱える柔軟性と、「スキーマオンリード」を実行して複数のスキーマを処理する能力 (厳密なスキーマを事前に定義する必要がない)
- ビジネスエンティティを詳細に表現できるため、リッチなクエリとアプリケーションが得られる (エンティティを厳密なリレーショナルスキーマとして定義する必要がない)
- 分断されたデータサイロの解消 (新規アプリケーションごとのデータベースは不要)
- アジャイルなデータ統合およびキュレーション (時間のかかる ETL や事前のデータモデリングは不要)
- データアーキテクチャ全体がシンプルに (様々なデータベースの組み合わせ＝「ポリグロットパーシステンス」は不要)
Oracle はリレーショナルデータベースで、行と列にデータを格納します。リレーショナルアプローチとマルチモデルアプローチの違いを示す具体例を3つ挙げます。
データモデリングとデータアクセス — Oracle のユーザーは、多くの場合、非常に複雑なリレーショナルスキーマを理解する必要があります。この構造では、単一のビジネスエンティティを定義するデータを多数のテーブルに分割することが必要な場合があります。その結果、列とフィールドの名前 (VARCHAR カラム) が、データベース管理者にしか理解できない不可解なものになります。つまり、データベース管理者しか、データへの適切なアクセス方法を知りません。例えば、医薬品に関するデータに対して、ユーザーは「アスピリン」、「アセチルサリチル酸」、「エキセドリン」、「バファリン」のうちどの名前でクエリすべきか知らなければなりません（これらはすべて同一の医薬品に対する異なった呼び名です）。違う名前でクエリを実行した場合、結果はほとんど返ってきません。
MarkLogic サーバーは、人間が読んで理解できるドキュメントモデルを使用することで、この問題を解決します。エンティティデータを分割する必要はありません。また、ビルトインの検索機能とセマンティック機能を利用して、ナレッジグラフのようなデータを検索できます。データベースや特定分野の専門家でなくても、データへのクエリを簡単に実行できます。
インデックスとパフォーマンス — Oracle では、データベース管理者はクエリのパフォーマンス維持のために、テーブルおよびインデックスの最適化を頻繁に行う必要があるため、多くの保守作業が必要です。例えば、insert のパフォーマンス維持のため、テーブルスペースのデフラグが頻繁に必要です (delete の量に応じて、おそらく週1回かそれ以上)。また、Oracle のインデックスでは、頻繁なリバランスと再インデックス付けが必要です。Oracle では、実行プランが頻繁に影響を受け、パフォーマンス維持のためには新しいプランを作成しなければなりません。Oracle オプティマイザを利用している場合、適切に保守されているシステムであっても、状況はさらに悪化する可能性があります。また、Oracle データレプリケーションを使用する場合は、トランザクションのパフォーマンスが低下する可能性があります。
MarkLogic サーバーはリレーショナルデータベースとは異なり、単語、語句、関係性、値、構造に自動的にインデックス付けするユニバーサルインデックスを使用します。ユニバーサルインデックスでは、作成、更新、同期のための保守は不要です。ユニバーサルインデックスに対するクエリのパフォーマンスは Google 検索のようであり、ワークロードが異なっても一貫性があります。
メタデータとデータガバナンス — Oracle では、メタデータのトラッキングには事前のプランニングが必要です。変更は複雑で、データの損失が頻繁に発生します。定義済みのスキーマを持つ他のリレーショナルデータベースと同様、新しいメタデータを扱うためには、列を追加する必要があります。しかしほとんどの場合、メタデータは破棄されるか、他の場所に格納されてしまいます。出自やリネージのメタデータはデータガバナンスに不可欠ですが、特に、複雑なデータ統合ライフサイクルでは、管理があまりに面倒になってしまいます。
MarkLogic サーバーは、どのような量のメタデータもデータ自体のすぐ隣に格納します (ドキュメントの属性が増えるようなものです)。出自とリネージのメタデータの格納には PROV-O 標準が使用されるため、あらゆるツールで認識されます。さらに、MarkLogic 内のあらゆるデータと同様、ハーモナイズやセマンティックによるエンリッチが可能です。リレーショナルアプローチでは、このようなことはできません。
Oracle はマルチモデルデータベースか？
ある意味では、Oracle の最新バージョンはマルチモデルデータベースです。ただし、Oracle は従来、純粋なリレーショナル以外のアプローチを冷笑していました。2015年の eWeek の記事で、Oracle 幹部のアンディ・メンデルソン氏は、マルチモデルデータベースを含めた NoSQL データベースは「シンプルなデータ管理用」であり、「生産性が極めて低く」、「限定的」であると語っていました。実際には、NoSQL 市場はその後急成長しました。2019年にメンデルソン氏が Oracle Open World で述べたところによると、Oracle は実は NoSQL マルチモデルデータベースだそうです。「リレーショナルデータベースは年月を経てマルチモデルデータベースになりました。Oracle はデータ型として JSON をサポートしています。XML もサポートします…」。
彼は間違っていません。JSON、XML、RDF を Oracle に読み込むことは可能です。しかし、Oracle は依然としてリレーショナルデータベースです。これまでのバージョンすべてと同様、本当の意味でのマルチモデルデータベースではありません。
Oracle は JSON をネイティブに格納しません。Oracle のドキュメントによると、「Oracle データベースでは、JSON データは (抽象的な SQL のデータ型 XMLType として格納される XML データとは異なり) 一般的な SQL データ型のVARCHAR2、CLOB、BLOB を使用して格納されます」。
その結果、JSON ドキュメントの値を抽出するには、JSON ドキュメント全体をトラバースしてデータを見つける必要があります。このアプローチには時間がかかります。パフォーマンス改善のために、Oracle は2つの対応策を推奨しています。一つは、データをマテリアライズドビューに抽出し、値を別の表にプッシュする方法です (シュレッディング)。もう一つは、ACID が保持されない JSON 検索インデックスです (トリガーされたときにしか更新されません)。
一般的に、Oracle のようなリレーショナルデータベースでは、マルチモデルのワークロードを扱うことは困難で、融通が利きません。リレーショナルデータベースでは、ドキュメントへのクエリのような単純な処理でも問題が発生するだけでなく、トリプルによるドキュメント同士のリンクや、XML と JSON の両方への同時クエリといった、より高度な機能を実行できません。MarkLogic サーバーは、これらを簡単に実行できます。
かつて、開発者はリレーショナルデータベースを使用せざるをえませんでした。みなが使っていたからです。ジェフ・ベゾス氏が2018年の株主宛て書簡で指摘したとおり、「開発者がリレーショナルデータベースを使い慣れているため、これが適さない場合でも使ってきた」のです。今日、ユーザーが使用できるデータベースの選択肢はかつてないほど広がっています。マルチモデルが広く普及するにつれて、採用の障壁は低くなっています。
データベース比較表
| MarkLogic サーバー | Oracle データベース | |
|---|---|---|
| データモデル |
|
|
| 検索＆クエリ |
|
|
| Indexing |
|
|
| データの一貫性 |
|
|
| セキュリティ |
|
|
| スケーラビリティ |
|
|
| デプロイメント |
|
|
| 成熟度 |
|
|
注：Oracle は Oracle NoSQL データベースという製品も提供しています。Oracle NoSQL データベースはキー/バリューストアで、MarkLogic サーバーなどのドキュメント指向のデータベースとは大きく異なります。キー/バリューストアは、ほとんどの場合キャッシュレイヤとして使用され、シンプルな低レイテンシの処理向けに最適化されています (データ統合用ではありません)。そのため、この比較では Oracle NoSQL は取り上げません。
MarkLogic と Oracle クラウドデータハブの比較
この比較では、MarkLogic データハブサービスと Oracle の「クラウドデータハブ」の似ている部分と異なる部分を紹介します。ここで「クラウドサービス」をカギ括弧で囲んでいるのは、Oracle が提供しているのは一元化された1つの製品ではないからです。Oracle のクラウドデータハブを使用する場合、MarkLogic と同等の機能を揃えるには、複数の Oracle Cloud 製品 (あるいは他のサードパーティー製品) を組み合わせる必要があります。
以下は、Oracle の「クラウドデータハブ」を実現するために組み合わせる必要がある Oracle 製品の一部です。
- Oracle Autonomous Database – OLAP 用に最適化された Oracle データベース
- Oracle Autonomous Transaction Processing – OLTP 用に最適化された Oracle データベース
- Oracle Spatial and Graph – 地理情報データ/クエリ、および一部の RDF グラフ格納に対応
- Oracle Text – 全文検索
- Oracle NoSQL Cloud Service – JSON 対応
- Oracle XML DB – XML 格納およびクエリ
- Oracle GoldenGate Cloud Service – オペレーショナルデータストア、一部の変換処理
- Oracle Data Integrator Cloud Services – ETL パイプラインおよび接続
- その他のBig Data Cloud Service – データ分析。Hadoop および Spark を活用
MarkLogic の方がクラウドサービスに適している理由
MarkLogic データハブサービスは、次の利点により、Oracle 製品の集合体よりも優れています。
- MarkLogic は、現代的なアジャイルアプローチにより、1/10の期間でデータを統合します (事前モデリングが膨大に必要な従来のアプローチとの比較)。
- MarkLogic の方が柔軟性が高く (マルチモデル vs リレーショナル基盤)、ドキュメントやトリプルを格納するための最適化が、より適切になされています。
- MarkLogic の方が導入、運用、保守がシンプルで時間がかかりません (MarkLogic は1製品、Oracleは多数の製品の集合体)。
- MarkLogic の方が低コストで、透明性が高いです (さらなる Oracle ELA を望む人は誰もいないはずです)。MarkLogic を選んだことにより、数億円のコストを削減したお客様の事例は多数あります (シェブロンの事例があります)。
MarkLogic データハブサービスでは、データ読み込みのための大がかりな事前モデリングは不要です。データを読み込む場合、目の前のビジネスニーズに必要なデータだけを追加します。電話番号や住所のような、反復される階層型の属性は JSON や XML ドキュメント形式で自然に表現できます。別のテーブルを作成する必要はありません。また、MarkLogic では、データは追加された時点でインデックスが付けられます。このためデータはすぐに発見可能になります。
データを統合する際、MarkLogic ユーザーは、データのカノニカルモデルの作成、データのマスタリング、メタデータによるエンリッチ、セマンティックの追加、プロセス全体のガバナンスを反復的に行っていきます。これにより、変化によるリスクを抑制しながら、下流のビジネスニーズを満たすデータサービスを極めて短期間で作成できます。また、MarkLogic は従来の BI や分析だけでなく、リアルタイムの業務アプリケーションにも使用できます。
クラウドのコンサンプション (消費)
クラウドではインフラの導入が短期間で済みますが、複雑になることが多く、適切な検討をしておかないとあっという間にコストが膨らむ可能性があります。コスト超過を防止するために、どの要素によってコストが決まるのか、また、クラウドサービスがどのように対応するのかを理解しておくことが重要です。サービスごとにバーストへの対処方法は大きく異なります (予測された通常の使用量を超えて需要がスパイクした場合)。コンサンプションベースの料金体系の場合、コストに大きな差が出ます。
MarkLogic のクラウドコンサンプション (消費) モデル
MarkLogic データハブサービスはコンサンプションモデルを使用しており、次の3つに基づいて課金されます。
- 帯域幅 – TB あたりの料金
- ストレージ – GB あたりの料金 (1か月単位)
- 演算処理 – MCU あたりの料金 (1時間単位)
MarkLogic データハブサービスは、クラスタを拡大/縮小する際に、ワークロードの状況を考慮します。業務、分析、キュレーションのワークロード別に拡張し、高いレベルの信頼性と応答性を実現します。このコンサンプションベースの料金体系により、複雑なクラウドサービスにありがちな予測不能なコストを心配する必要がなくなります。
MarkLogic データハブサービスでは、拡張とバーストがシンプルで予測可能です。MarkLogic は、「繰り越し」を含むシステムを使用しています。そのため、貯まった未使用分が次の請求分に繰り越されます。繰り越しは、キャパシティの最大12倍 (2倍ではなく) まで貯められます。既に支払い済みの繰り越しクレジットの使用には追加料金は不要です。このアプローチでは、ピークのプロビジョニングにおけるコスト増につながる失敗を回避でき、さらに、スパイク発生時のコストが制御可能になります。
Oracle のクラウドコンサンプション (消費) モデル
Oracle もコンサンプションベースの課金方法を採用しており、OCPU (Oracle Compute Unit) という独自のクラウドクレジット単位を使用しています。これに加えて帯域幅およびストレージの料金を支払う必要があります。
いろいろ組み合わされた Oracle クラウドサービスは、MarkLogic データハブサービスよりも費用が大きくなります。これは、実行するサービスが多いほど、必要なインフラが倍々で増えていくためです (データの複製、バックアップと復旧、冗長なインデックスなど)。Oracle では各サービスのキャパシティごとに支払いが必要ですが、MarkLogic では、1つの包括的サービスに対する支払いとなります。クラウドクレジット単位の適用には若干不明瞭な部分もあるため、正確な見積もりは困難ですが、ほとんどの場合、Oracle のコストは MarkLogic の3倍と推定されます。Oracle の料金体系がしばしば懸念材料になり、驚くような請求金額を受け取るリスクがあることは、企業やアナリストにとっては有名な話です。
また上記のコスト比較には、各サービスのバーストへの対処方法の違いは含まれていません。どちらの製品もバーストに対応しますが、Oracle では MarkLogic よりも予測が困難で、制約が多く、高コストになります。Oracle では、バースト時の超過キャパシティは従量課金制で、バースト対応の限度はサブスクリプションの2倍です (Oracle のドキュメントを参照)。また、バースト限度を超過した場合、Oracle Cloud はそれを通知したうえでアカウントを一時停止します (Oracle のドキュメントを参照)。
クラウドの未来
MarkLogic はクラウドニュートラルです。主要なクラウドプロバイダとは戦略的パートナーとなっており、MarkLogic データハブサービスを各プロバイタのエコシステムにシームレスに統合できます。MarkLogic は、リレーショナルデータベースではなく (AWS や Azure もリレーショナルデータベースを提供しています)、明確に差別化された製品を提供しています。また必要に応じて、将来クラウドプロバイダを変更できる柔軟性も備えています。
これまで Oracle はデータベースソフトウェア市場を支配してきましたが、この状況は今後変わってくるでしょう。未来の中心となるのは「クラウドデータ管理」であり、これは Oracle が得意な分野ではありません。フォーブスの記事で指摘されているとおり、「調査対象 (のCIO) のうち、自社のクラウドコンピューティングに最も欠かせないベンダーとして Oracle を挙げたのはわずか2％」なのです。
クラウド比較表
次の表では、MarkLogic データハブサービスと Oracle Cloud コンポーネント (MarkLogic と同等の機能を実現するのに必要なもの) を比較しています。
| MarkLogic データハブサービス | Oracle「データハブクラウド」コンポーネント* | |
|---|---|---|
| 統合プラットフォーム |
|
|
| 基盤となるデータベース |
|
|
| データの読み込み |
|
|
| データのキュレーション |
|
|
| データへのアクセス |
|
|
| セキュリティ＆ガバナンス |
|
|
| 拡張性 |
|
|
| コスト |
|
|
*Autonomous DB と、オプション、Data Integrator、GoldenGate、その他、上記の関連クラウドサービスを含む
Oracle が MarkLogic よりも適しているケース
Oracle は、従来のリレーショナルデータ (行と列でモデリングされ、SQL でクエリを実行する) の格納および管理用に設計されています。このような構造化アプローチとして (SQL とリレーショナルモデリングのスキルが世間で定着していることもあり)、Oracle は、それに適したトランザクショナルアプリケーションや分析アプリケーションを実行する目的で使われています。Oracle はオンプレミスソフトウェアのリーダーとしての歴史が長いため、多くの組織は既に Oracle と ELA を締結しています。データが予測可能で (大きく変化しない)、オンプレミスで管理され、ライセンスが使用可能ならば、Oracle を使い続けることが道理にかなっています。
一方、データ管理のワークロードが増大し、多様化、複雑化している場合、またクラウドに移行する場合は、MarkLogic を選択した方が良いでしょう。
MarkLogic が Oracle よりも適しているケース
データ統合で使用する場合、MarkLogic の方が Oracle よりも適しています (特に業務と分析の両方を扱い、大規模で複雑なデータセットが必要な場合)。これは、何らかの 360° ビュー、業務分析、検索、発見などのためにデータハブを構築する場合も同様です。データが乱雑で常に変わるのであれば、RDBMS よりもマルチモデルデータベースを備えたデータハブの方が適しています。
MarkLogic は、Oracle を単純にリプレースするものではありません。MarkLogic は、Oracle のデータを簡単に読み込むこともできます。MarkLogic には、従来の SQL クエリ用のリレーショナルビュー (表としての表現)や、ワンクリックで主要 BI ツールと統合できる機能もあります。これらの理由から、Oracle と MarkLogic をそれぞれが得意とする分野で併用している企業は多数あります。例えば、Oracle GoldenGate を使って上流の Oracle システムのデータを集約してから、MarkLogic データハブに読み込むことができます。これはよくある使い方です。Oracle を将来的にはやめる予定でも、MarkLogic を使い始める際に既存の Oracle ライセンスも活用し続けることは、多くの場合において理に適っています。
Oracle よりも MarkLogic を選んだお客様
Oracle ではなく MarkLogic が選ばれた具体例をいくつか紹介します。
- シェブロン – MarkLogic による「アセット 360」データハブは、設備、装置、その他の情報を含む精製所データの全体像を提供し、安全性と効率化に貢献しています。シェブロンのチーフアーキテクトによると、「1000個のものをリレーショナル構造でモデリングしようとしたら、かなり大変です。この形式およびデータ管理手法により、数年来のマスターデータ管理の問題を解決できました」。
- ABN アムロ – MarkLogic は4,000万件以上の取引レコードのリアルタイム分析を行っています。ABN アムロのプリンシパルアーキテクトによると、「規制要件変更にはすばやく対応する必要があります。MarkLogic を選んだ理由は、取引データをリレーショナルデータベースで扱うのは非常に難しいからです」。
- HealthCare.gov – MarkLogic は、28万人の同時接続ユーザー、毎秒6,500件のトランザクションを処理し、米国民1,000万人以上の保険加入に貢献しています。スティーブン・パレンテ博士によると、これは「米国史上最大の政府による個人データ統合プロジェクト」です (MarkLogic の成功は、Oracle のオレゴン州での失敗と対照的です)。
- L.A. Care – MarkLogic は、医療機関データの精度確保、検証、分析、レポート、公開をサポートしています。チーフデジタルオフィサーによると、「MarkLogic の技術により、市場競争力、そしてコストとデリバリーの両面で、効率が10倍アップしました。この結果には、大いに満足しています」。
次のステップ
このクイックツアーでは、リレーショナルアプローチによってデータ統合が妨げられ、リスクが増大する仕組みを詳しく紹介します。
この3部構成のブログシリーズは、金融サービスのベテランエンジニアが執筆しており、組織がマルチモデルに移行している理由、重要なコンセプトのいくつか、そして移行のタイミングを説明しています。
この無料の電子書籍は、データ統合の歴史と、リレーショナル＆ETL アプローチの根本的問題、そして MarkLogic がそれをどうシンプルにするのかについて詳しく説明しています。
