1 Oracle Database API for MongoDBの概要

Oracle Database API for MongoDBを使用すると、アプリケーションはMongoDBコマンドを使用してOracle Database内のJSONドキュメントのコレクションと対話できます。

Oracle Database API for MongoDBは、Oracle Autonomous Database Serverlessの一部として提供されます。Oracle Cloud Infrastructure Consoleを使用して有効にできます。Oracle Autonomous Database Serverlessの使用MongoDBのアクセスの構成

Oracle REST Data Services (ORDS)のリリース22.3以上がある場合、リリース21c以降のすべてのOracleデータベースと、リリース19cのすべてのOracle Autonomous Database (サーバーレス、専用またはcloud@customer)でMongoDB APIを使用できます。APIの有効化の詳細は、Oracle REST Data Servicesインストレーションおよび構成ガイドOracle API for MongoDBサポートを参照してください。

関連項目:

Oracle Database API for MongoDBでのAutonomous Database (Autonomous JSON Databaseを含む)の使用の詳細は、Oracle Autonomous Database Serverlessの使用Oracle Database API for MongoDBの使用。ここでは、セキュリティや接続など、APIで使用するためのデータベースの構成について説明します。

1.1 Oracle Database API for MongoDBの目的

Oracle DatabaseはMongo-speakを認識します。それがOracle Database API for MongoDBの目的です。

MongoDB NoSQLデータベースと対話する1つ以上のアプリケーションがあり、そのデータをOracle Databaseに移行する必要があります。または、JSONドキュメントの比較的シンプルなコレクションがあり、SQL (Structured Query Language)を学んで使用しようとは考えていません。または、MongoDBコマンド、特にアプリケーションのビジネス・ロジック用のコマンド(例による問合せ)のみでなく、データ定義(コレクションおよび索引の作成)、データ操作(CRUD操作)およびデータベース管理(ステータス情報)用のコマンドを使用しており、引き続き使用しようと考えています。固定データ・スキーマがなく、使いやすいドキュメント中心のAPIであるJSONドキュメント・ストアの柔軟性を高く評価しています。

MongoDBを使用するアプリケーションがある場合に、高度なセキュリティ、完全なACIDトランザクション(原子性、一貫性、分離、永続性)、あらゆる種類のデータを備えたJOINの標準化、および分析、機械学習、レポート機能を提供することで、それらをより強化しようと考えています。

簡単に言うと、Oracle Database API for MongoDBまたはMongo APIは、MongoDBを利用する開発者にとって、このようなメリットがあります。これは、MongoDBワイヤ・プロトコルをOracle Databaseによって実行されるSQL文に変換します。JSONドキュメントストア・アプリケーションの開発にこれまで使用してきたドライバ、フレームワークおよびツールを今後も引き続き使用できます。

Oracle Databaseはコンバージド・データベースです。これはマルチモデルかつ多言語です。異なる種類のデータベースを1つであるかのようにまとめ、様々な機能を横断した連携を実現し、様々なワークロードおよびデータ・モデルをサポートします。

また、Oracle Databaseはマルチテナントでもあるため、複数のチームや目的に対して統合と分離を両立できます。さらに、セキュリティ、アップグレード、パッチ適用、メンテナンスに共通の単一アプローチが用意されています。ただし、Autonomous JSON DatabaseなどのAutonomous Oracle Databaseを使用する場合、そのようなデータベースの管理のすべての責任はオラクル社が負います。さらに、自律型データベースへのAlways Freeアクセスもあります。

標準の宣言型言語であるSQL (Structured Query Language)がOracle Databaseでの処理の基礎となります。Mongo-speakまたはSimple Oracle Document Access (SODA)を使用して、一般的なアプリケーション開発言語でアプリケーションを開発することもできますが、SQLはそれらのすべての背後にあり、アプリケーションがOracle Database上の他のあらゆるものと適切に連携できるようにしています。

1.2 Oracle Database API for MongoDB向けのツールおよびドライバ

Oracle Database API for MongoDBでは、様々なMongoDBツールおよびドライバがサポートされています。

接続のロード・バランシングに対応した次のバージョン以降のツールおよびドライバを使用することをお薦めします。

  • C 1.19.0

  • C# 2.13.0

  • Compass 1.28.1

  • Database Tools 100.5.0 (mongoexportmongorestoremongodumpなどを含む)

  • Go 1.6.0

  • Java 4.3.0

  • MongoSH 0.15.6

  • Node.jsドライバ4.1.0

  • PyMongo 3.12.0 (Python言語用)

  • Ruby 2.16.0

  • Rust 2.1.0

これらのドライバは、https://www.mongodb.com/docs/drivers/からダウンロードできます。

ノート:

Oracle Database API for MongoDBへの入力およびそこからの出力の例では、シェルmongoshの構文を使用します。

1.3 用語および概念: MongoDBおよびOracle Database

MongoDBで使用されるアプリケーション・ユーザー用語と概念をいくつか示し、それらとOracle Databaseとの関連について説明します。

同じ用語の一部は、Oracle Database API for MongoDBでも使用されます。通常、アプリケーション開発者はこのような用語の基礎となるOracle Databaseの概念やテクノロジを考慮する必要はありません。

表1-1 アプリケーション・ユーザー用語

用語 説明
データベース

コレクションのセット。

Oracle Databaseでは、これはデータベースのスキーマに対応します。

データベースという用語の使用は混乱を招く可能性があるため、このドキュメントではOracle Databaseに対してはデータベースという用語を使用し、MongoDBでデータベースと呼んでいるものに対してはスキーマまたはデータベース・スキーマという用語を使用しています。

ユーザー

ログイン目的の場合、Oracle Database API for MongoDBのユーザーはOracle Databaseユーザーであり、データベース・スキーマとも呼ばれます(前項を参照)。

特定のスキーマ(データベース)内のコレクションを使用するには、MongoDB PLAIN $externalメカニズムを使用し、そのスキーマの資格証明を指定して、Oracle Database API for MongoDBにログインします。

rootユーザー(MongoDBロールrootを持つユーザー)は、追加のデータベース・スキーマを作成できます。また、rootユーザーはスキーマごとに個別にログインする必要なく、任意のスキーマのコレクションを使用できます。

コレクション

コレクションには、一連のドキュメントが含まれています。

コレクション名は、特定のデータベース・スキーマで一意です。異なるスキーマ内にある場合、異なるコレクションに同じ名前を付けることができます。

Oracle Databaseでは、表またはビューがコレクションの基礎となります。表名はコレクション名から導出され、通常は同じになります。(ただし、Oracle Databaseによって予約されている単語を使用するコレクション名などは例外です。)通常、コレクション内のすべてのドキュメントがJSONドキュメントです。

ドキュメント

コレクション内のデータを格納する基本単位。

Oracle Databaseでは、ドキュメントはコレクションの基礎となる表またはビューの行にほぼ対応します。

ドキュメントは通常、JSONドキュメントであり、JSONデータのみが含まれています。Oracle Autonomous Databaseでは、ドキュメントは常にJSONドキュメントです。

Oracle Autonomous Databaseでは、ドキュメントの格納に使用される表の名前はdataです。

主キー

Oracle Databaseでは、主キーは表またはビューの行を一意に識別するために使用します。

MongoDBは、ドキュメント内の一意の_idフィールドを使用してドキュメントを識別します。Oracle Databaseでは、JSONドキュメントの主キーはidという列に格納されます。この値は、ドキュメントの_idフィールドの値に自動的に設定されます。「ドキュメント・キー: 相違点と変換(23aiより前のOracle Database)」を参照してください。

問合せ式

コレクションのドキュメントを問い合せるために、アプリケーション・クライアントによってサーバー(Oracle Database)に送信されるJSONオブジェクト。

このオブジェクトには、$で始まる名前の問合せ演算子フィールドを含めることができます。演算子は解釈され、その操作はコレクションを処理するために起動されます。サーバーは、その処理結果をクライアントに返します。

問合せ式は通常、コレクションの問合せに使用しますが、ドキュメント内のデータの投影または更新にも使用できます。

Oracle Database API for MongoDBは、問合せ式をSQL (Structured Query Language)問合せに変換します。

索引

索引により、コレクションに対する処理(ドキュメントの問合せ、挿入、更新および削除)を実行する際のパフォーマンスが向上します。

索引名は、特定のデータベース・スキーマで一意です。異なるスキーマ内にある場合、異なる索引に同じ名前を付けることができます。

ノート:

Oracle Databaseパラメータのcompatible23より小さい場合、索引を作成または削除するためのMongoDBコマンドは、Oracle Database API for MongoDBで無視されます。かわりに、JSONデータに関連するOracle Database索引を作成する必要があります。

パイプライン

MongoDB集計操作では、複数の操作をまとめて連鎖させ、パイプラインとして順次起動します。

Oracle Databaseパラメータのcompatible23より小さい場合、MongoDBの集計パイプラインは使用されず、異なる方法でOracle Database API for MongoDBが集計操作を実行します。MongoDB集計パイプラインのサポートを参照してください。

関連項目:

1.4 コレクション表のデフォルトのネーミング

デフォルトでは、ドキュメント・コレクションの基礎となるデータベース表の名前はコレクション名から導出されます。

デフォルトで提供されているものと異なる表名が必要な場合は、カスタム・コレクション・メタデータを使用して明示的に名前を指定します。

デフォルトの表名は、指定したコレクション名から次のように導出されます。

  1. コレクション名の各ASCII制御文字および二重引用符(")はアンダースコア(_)に置き換わります。

  2. 次の条件のすべてが適用される場合、名前のすべての文字は大文字に変換され、表名を示します。この場合、SQLコードで表名を引用符で囲む必要はありません。これ以外の場合、表名を引用符で囲む必要があります。

    • 名前内の文字がすべて小文字か、すべて大文字である。

    • 名前がASCII文字で始まる。

    • 名前内の各文字がASCIIの英数字、アンダースコア(_)、ドル記号($)または番号記号(#)である。

      ノート:

      Oracle識別子名にドル記号文字($)または番号記号文字(#)を使用しないことをお薦めします。

例:

  • コレクション名「col」と「COL」は、両方とも「COL」という名前の表になります。SQLで使用する場合、表名は大/小文字の区別なく解釈されるため、二重引用符(")で囲む必要はありません。

  • コレクション名「myCol」は「myCol」という名前の表になります。SQLで使用する場合、表名は大/小文字を区別して解釈されるため、二重引用符(")で囲む必要があります。

1.5 Mongo DB APIとJSONリレーショナル二面性ビューの使用

Oracle Database API for MongoDBは、JSONリレーショナル二面性ビューでサポートされているドキュメントで使用できます。このようなドキュメントは、基礎となる表データに基づいて自動的に生成されます。

JSONリレーショナル二面性ビューは、Oracle Databaseリリース23ai以降でのみサポートされています。

JSONリレーショナル二面性ビューでは、リレーショナル・データベース表に格納されているデータがJSONドキュメントとして公開されます。そのドキュメントは、要求に応じてマテリアライズされるため、格納されません。二面性ビューでは、データに概念的二面性と運用的二面性が両方与えられます: それは、リレーショナル形式と階層形式の両方で編成されます。複数の異なる二面性ビューを、同じ表1つ以上に格納されたデータに基づくようにし、共有されている同じデータに複数の異なるJSON階層を提供できます。

これはつまり、アプリケーションで、JSONドキュメントのコレクションとして、または関連する一連のデータベース表および列として、同じデータにアクセス(作成、問合せ、変更)できるということであり、両方の手法を同時に採用できます。

二面性ビューによって実現されるドキュメントは、通常のドライバ、フレームワーク、ツールおよび開発方法を使用して、これまでと同じ方法で操作できます。具体的に述べると、アプリケーションで任意のプログラミング言語を使用できるということです。

アプリケーションでは、二面性ビューでサポートされているドキュメント・コレクションが、ドキュメントがJSONデータ型の表列に格納されているかのように使用されます。MongoDB APIコールでは、二面性ビュー名をcollection-name引数として使用します。

ノート:

ビューの作成時に二面性ビュー名が引用符で囲まれていない場合は、必ず、MongoDB APIコールでその名前を大文字として渡してください。たとえば、ビューの作成時にmy_dvが使用されていた場合は、コレクション名として"MY_DV"を渡します。ビューの作成時に"my_dv"が使用されていた場合は、"my_dv"を渡します。

重要なユースケースの1つである、MongoDB APIアプリケーションでは、既存のデータベース・データを簡単に利用できます。そのデータを基に1つ以上の二面性ビューを作成するだけで、JSONコレクションがサポートされます。

JSONリレーショナル二面性の重要な側面は、様々な種類のJSONドキュメントで同じデータを共有できることです(また、リレーショナル表で同じデータを共有できます)。二面性ビューをどのように定義したかで、どのデータが共有されるかとその方法(誰がどのドキュメント部分に対してどの種類の更新操作を実行できるか)が決まります。

MongoDB APIで使用するJSON二面性ビューの作成

MongoDB APIを使用してJSONリレーショナル・ビューを作成することはできません。これを行うには、SQL文CREATE JSON RELATIONAL DUALITY VIEWを使用します。

すべての二面性ビューは、MongoDB APIと互換性があります。それらには必ず、そのドキュメント識別子としてフィールド_idがあります。フィールド_idの値により、その二面性ビューの基になるルート表の主キー列が値である、ドキュメント・フィールドを示しています。

  • 主キー列が1つのみ,の場合は、二面性ビューを定義するときに、その列をフィールド_idの値として使用します。たとえば、例1-1で示されている_id : race_idです。

  • 複数の主キー列,がある場合は、そのビューを定義するときに、オブジェクトをフィールド_idの値として使用します。そのオブジェクトのメンバーにより、値が主キー列であるドキュメント・フィールドを指定します。たとえば、カーレースの二面性ビューがあるとします。それには2つの主キー列race_idrace_yearがあり、それらを一緒に使用することでルート表の行が一意に識別され、どちらか1つでは識別されません。二面性ビュー定義でのこの_idフィールドにより、ドキュメント・フィールドraceIdおよびyearが、それぞれ主キー列race_idおよびrace_yearにマップされます。

    _id : {raceId : race_id, year : race_year}

    主キー列が1つのみの場合でも、必要に応じて_idにオブジェクト値を使用できます。これにより、わかりやすいフィールド名を指定できます。たとえば、ここでは、単一の主キー列race_idで、フィールドraceIdの値、およびフィールド_idの値が提供されます:

    _id : {raceId : race_id}

フィールド_idによってそのマップ先の主キー列に提供される値が、これらの列に挿入可能である必要があります。つまり、それらのデータ型に、列の型との互換性が必要です。たとえば、フィールド_idが、SQL型がNUMBERの単一の主キー列にマップされている場合は、挿入するドキュメントの_id値が数値である必要があります。そうでない場合は、挿入しようとするとエラーが発生します。

挿入するドキュメントに_idフィールドを明示的に含めなかった場合は、ObjectId値で、それが自動的に追加されます。(_idフィールドでObjectId値を明示的に使用することもできます。)ObjectId値は、二面性ビューでSQL型RAWの列にマップされているフィールドにのみ使用できます。

例1-1 GraphQLの使用によるJSON二面性ビューRACE_DVの作成

この例では、カーレースのレース・ドキュメントをサポートする、二面性ビューrace_dvを作成します。

CREATE JSON RELATIONAL DUALITY VIEW race_dv AS
  race @insert @update @delete
    {_id : race_id
     name   : name
     laps   : laps @noupdate
     date   : race_date
     podium : podium @nocheck
     result : driver_race_map @insert @update @delete
       [ {driverRaceMapId : driver_race_map_id
          position        : position
          driver @noinsert @update @nodelete
                 @unnest {driverId : driver_id}")
                          name     : name}} ]};

この定義は、JSONリレーショナル二面性開発者ガイドGraphQLの使用による二面性ビューRACE_DVの作成での定義と同じです。類似する、ドライバおよびレースのドキュメントの二面性ビュー作成については、そのドキュメントを参照してください。この例のSQLコードでは、Oracle GraphQLコードを埋め込みます。または、SQLの使用によるネストされていないドライバ情報を含む二面性ビューRACE_DVの作成で示すように、定義にSQLコードのみを使用することもできます。

この二面性ビューでは、次のようなレース・オブジェクトを含むJSONドキュメントがサポートされています。それらにはresultフィールドが含まれており、その値は、指定したレースにおけるドライバとその結果の順位を示すオブジェクトの配列です:

{"_id" : 201,
"name" : "Bahrain Grand Prix",
"laps" : 57,
"date" : "2022-03-20T00:00:00",
"podium" : {...},
"result" : [ {"driverRaceMapId" : 3,
              "position" : 1,
              "driverId" : 103,
              "name" : "Charles Leclerc"},... ]}

ドキュメント識別子フィールド_idの値は、ルート表raceの単一の主キー列race_idから取得されます。たとえば、値が201である_idフィールドで識別されたドキュメントは、二面性ビューの基になるルート表(race)の主キー列race_id201があるデータ行から生成されます。

このビューでサポートされているドキュメントの生成では、表driver_race_map内の列driver_race_map_idpositionおよびdriver_id、ならびに表driver内の列nameのデータが自動的に結合されます。

注釈(GraphQLディレクティブ) @insert@updateおよび@deleteはぞれぞれ、そのビューでサポートされているドキュメントをアプリケーションで挿入、更新および削除できることを示すために使用されますが、それらで実行できるのはドキュメントのdriverフィールドに対する更新操作のみであり(レース・ドキュメントの変更時にドライバの挿入や削除はできない)、lapsフィールドの更新はできません(レース・ドキュメントの更新時に周回数を変更することはできない)。

podiumに適用される@nocheck注釈により、レース・ドキュメント内のフィールドpodiumの更新はそのドキュメントの状態/バージョン(そのETAG値)がチェックされる要因にならないことが指定されています。

関連項目: