9.8. MongoDB Translator

mongodb というタイプによって認識される MongoDB トランスレーターは、MongoDB データベースにあるデータのリレーショナルデータベースビューを提供します。このトランスレーターは、Data Virtualization SQL クエリーを MongoDB ベースのクエリーに変換することができます。これは、すべての SELECT、INSERT、UPDATE、DELETE コールを提供します。

MongoDB は、独自のクエリー言語を持つドキュメントベースの「スキーマレス」データベースです。これは、リレーショナルデータベース概念または SQL クエリー言語と完全にマッピングされません。スケーラビリティーやパフォーマンスを向上させるために、MongoDB などの NOSQL ストアを使用するシステムが増えています。たとえば、監査ログの保存や Web サイトデータの管理などのアプリケーションは MongoDB に適しており、リレーショナルデータベースの構造は必要ありません。MongoDB は JSON ドキュメントをプライマリーストレージユニットとして使用し、それらのドキュメントには親ドキュメント内に追加の組み込みドキュメントを含めることができます。組み込みドキュメントを使用することで、MongoDB は、リレーショナルデータベースでクエリーを行うために重複したデータまたは結合を要求する正規化のために関連情報を同じ場所に配置し、リレーショナルデータベースでクエリーを実行します。

MongoDB が Data Virtualization と連携するには、MongoDB トランスレーターが、リレーショナルデータベースとドキュメントベースのストレージ間のバランスを実現できる MongoDB ストアを設計することです。「スキーマなしの」設計の利点は、開発時に非常に適しています。しかし、「スキーマレス」設計では、アプリケーションのバージョン間の移行時に問題を引き起こす可能性があり、データのクエリー時に、返された情報の効率的な使用が可能になります。

困難であり、既存の MongoDB コレクションに基づいてスキーマを取得することができないため、Data Virtualization は他の変換者と比較して、逆順で問題を順守します。MongoDB を使用する場合は、Data Virtualization メタデータを使用して MongoDB スキーマを定義する必要があります。Data Virtualization は、リレーショナルデータベースをメタデータとしてのみ許可するため、テーブル、手順、および関数を使用して、リレーショナルデータベース用語で MongoDB スキーマを定義する必要があります。MongoDB の目的で、Data Virtualization メタデータが拡張され、テーブルに定義されたエクステンションプロパティーを提供して MongoDB ベースのドキュメントに変換するようになりました。これらのエクステンションプロパティーを使用すると、MongoDB ドキュメントが構造化され、保存される方法を定義できます。テーブルで定義された関係（primary-key、external-key）と、そのカーディナリティー（ONE-to-ONE、ONE-to-MANY、MANY-to-ONE）に基づいて、関連の情報をコロケーションの親ドキュメントと共に埋め込むことができるようにマッピングされます。そのため、リレーショナルデータベースベースの設計ですが、MongoDB でドキュメントベースのストレージです。

MongoDB トランスレーターの主な対象者は何ですか？

上記は、すべてのユーザーのニーズを満たさない可能性があります。MongoDB のドキュメント構造は、現在定義されている Data Virtualization よりも複雑になります。これは最終的にデータ仮想化の今後のバージョンで追いつくことを期待しています。これは現在以下の目的で設計されています。

リレーショナルデータベースを使用しているユーザーで、データを MongoDB に移動/移行して、現在実行しているエンドユーザーアプリケーションを変更せずにスケーリングとパフォーマンスを活用します。
シーケンスされた SQL 開発者であるが、MongoDB の経験がないユーザー。これにより、MongoDB を直接アプリケーション開発者として使用する場合と比較して、エントリーのバリアが低くなります。
MongoDB ベースのデータを他のエンタープライズデータソースのデータと統合したいユーザー。

用途

仮想データベースの DDL で使用するトランスレーターの名前は「mongodb」です。以下に例を示します。

CREATE DATABASE nothwind;
USE DATABASE nothwind;
CREATE SERVER local FOREIGN DATA WRAPPER mongodb OPTIONS ("resource-name" 'java:/mongoDS');
CREATE SCHEMA northwind SERVER local;

SET SCHEMA northwind;
IMPORT FROM SERVER local INTO northwind;

MongoDB トランスレーターは、シナリオにおける既存のドキュメントコレクションに基づいてメタデータを派生させることができます。ただし、複雑なドキュメントを使用する場合は、メタデータの解釈が正確になる可能性があります。このような場合には、メタデータを定義する必要があります。たとえば、以下の例のように DDL を使用してスキーマを定義できます。

<vdb name="nothwind" version="1">
    <model name="northwind">
        <source name="local" translator-name="mongodb" connection-jndi-name="java:/mongoDS"/>
            <metadata type="DDL"><![CDATA[
                CREATE FOREIGN TABLE  Customer (
                    customer_id integer,
                    FirstName varchar(25),
                    LastName varchar(25)
                ) OPTIONS(UPDATABLE 'TRUE');
            ]]> </metadata>
    </model>
<vdb>

Data Virtualization を使用してテーブルに対して以下の INSERT 操作が実行されると、MongoDB トランスレーターは MongoDB にドキュメントを作成します。

    INSERT INTO Customer(customer_id, FirstName, LastName) VALUES (1, 'John', 'Doe');

{
  _id: ObjectID("509a8fb2f3f4948bd2f983a0"),
  customer_id: 1,
  FirstName: "John",
  LastName: "Doe"
}

PRIMARY KEY がテーブルに定義されている場合、その列名は MongoDB コレクションで "_id" フィールドとして自動的に使用され、以下の例のようにドキュメント構造は MongoDB に保存されます。

    CREATE FOREIGN TABLE  Customer (
        customer_id integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE');

{
  _id: 1,
  FirstName: "John",
  LastName: "Doe"
}

Customer テーブルで複合 PRIMARY KEY を定義すると、結果となるドキュメント構造は以下の例のようになります。

    CREATE FOREIGN TABLE  Customer (
        customer_id integer,
        FirstName varchar(25),
        LastName varchar(25),
        PRIMARY KEY (FirstName, LastName)
    ) OPTIONS(UPDATABLE 'TRUE');

{
  _id: {
         FirstName: "John",
         LastName:  "Doe"
       },
  customer_id: 1,
}

データ型

MongoDB トランスレーターは、BLOBS、CLOBS、XML など、Data Virtualization データ型の自動マッピングを MongoDB データ型に提供します。LOB マッピングは MongoDB の GridFS をベースにしています。アレイは以下の形式になります。

{
  _id: 1,
  FirstName: "John",
  LastName: "Doe"
  Score: [89, "ninety", 91.0]
}

ユーザーは function array_get を使用してアレイ内の個別のアイテムを取得したり、ARRAYTABLE を使用してアレイを表形式構造に変換することもできます。

注記

組み込みドキュメントがアレイにある場合でも、埋め込みドキュメントの処理はスカラー値とアレイとは異なることに注意してください。

注記

トランスレーターは通常の式、MongoDB::Code、MongoDB::MinKey、MongoDB::MaxKey、および MongoDB::OID では機能しません。

注記

同じキーの混合タイプの値を含むドキュメントでは、列を検索不可としてマークする必要があります。そうでないと、MongoDB は列に対して述語と正しく一致しません。キーは、混合タイプとして、1 つのドキュメントの文字列値として表され、別のドキュメントの整数として使用されます。詳細は、以下の表の importer.sampleSize プロパティー を参照してください。

インポーターのプロパティー

インポータープロパティーは、物理ソースからメタデータをインポートする際にトランスレーターの動作を定義します。

インポーターのプロパティー

Expand

名前	説明	デフォルト
excludeTables	インポートから除外する正規表現。	null
includeTables	インポートからのテーブルを含む正規表現。	null
sampleSize	構造を判断するためのサンプルドキュメントの数。ドキュメントに別のフィールドがある場合、または異なるタイプのフィールドがある場合は、1 を超える値である必要があります。	1
fullEmbeddedNames	埋め込みテーブル名の前に親を付けるかどうか（例： parent_embedded）。false の場合、テーブルの名前はフィールドの名前になり、既存のテーブルまたは他の埋め込みテーブルと競合する可能性があります。	false

複雑なドキュメントを構築するための MongoDB メタデータ拡張プロパティー

上記の DDL またはその他のメタデータ機能を使用して、リレーショナルデータベースのテーブルを MongoDB のドキュメントにマップできます。ただし、MongoDB を効果的に使用するには、単一の MongoDB クエリーでデータをクエリーできるように、関連情報を同じ場所に配置できる複雑なドキュメントを構築する必要があります。リレーショナルデータベースとは異なり、MongoDB で結合操作を実行できません。その結果、複雑なドキュメントをビルドしない限り、複数のクエリーを実行してデータを取得し、手動で参加する必要があります。MongoDB のパワーは、「組み込み」ドキュメント、アレイなどの複雑なデータ型のサポート、およびそれらをクエリーするための集約フレームワークの使用をサポートしています。このトランスレーターは、ゴールを達成する方法を提供します。

MongoDB で複雑な埋め込みドキュメントを定義しない場合、Data Virtualization は参加処理にステップを表示し、その機能を提供します。ただし、MongoDB 自体の力を利用してデータのクエリーを行い、不必要なデータを組み込み、パフォーマンスを改善したい場合は、これらの複雑なドキュメントの構築について確認する必要があります。

MongoDB トランスレーターは、複雑な「組み込み」ドキュメントの構築に役立つ他の Teiid メタデータプロパティーと 2 つの追加のメタデータプロパティーを定義します。Data Virtualization スキーマのメタデータの詳細は、「スキーマオブジェクトの DDL メタデータ」を参照してください。DDL で以下のメタデータプロパティーを使用できます。

teiid_mongo:EMBEDDABLE: つまり、このテーブルで定義されたデータは、任意の親ドキュメントの「埋め込み可能な」ドキュメントとして含めることができます。親ドキュメントは外部キー関係で参照されます。このシナリオでは、Data Virtualization は MongoDB ストアに複数のデータのコピーと、独自のコレクションにあるデータのコピーと、このテーブルと関係のある各親テーブルのコピーを保持します。組み込み可能な別のテーブル内に埋め込み可能なテーブルをネスト化することもできますが、一部制限があります。テーブルでこのプロパティーを使用します。テーブルが存在すると、その関係がすべて含まれます。たとえば、「製品」のカテゴリーを定義する「カテゴリー」テーブルは製品とは独立しており、「製品」テーブルに埋め込むことができます。
teiid_mongo:MERGE: これは、このテーブルのデータが定義された親テーブルにマージされることを意味します。親ドキュメントに埋め込まれたデータのコピーは 1 つだけです。親ドキュメントは、外部キー関係を使用して定義されます。

上記のプロパティーと FOREIGN KEY 関係を使用して、MongoDB で複雑なドキュメントを構築する方法を説明します。

用途

指定されたテーブルには、MongoDB でネスト化のタイプを定義する teiid_mongo:EMBEDDABLE プロパティーまたは teiid_mongo:MERGE プロパティーのいずれかを含めることができます。1 つのテーブル内で両方のプロパティーを使用することはできません。

ONE-2-ONE マッピング

ONE-2-ONE 関係を表す現在の DDL 構造は次のようになります。

    CREATE FOREIGN TABLE  Customer (
        CustomerId integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE Address (
        CustomerId integer,
        Street varchar(50),
        City varchar(25),
        State varchar(25),
        Zipcode varchar(6),
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId)
     ) OPTIONS(UPDATABLE 'TRUE');

デフォルトでは、サンプルデータと同様に MongoDB で 2 つの異なるコレクションを生成します。

Customer
{
  _id: 1,
  FirstName: "John",
  LastName: "Doe"
}

Address
{
  _id: ObjectID("..."),
   CustomerId: 1,
   Street: "123 Lane"
   City: "New York",
   State: "NY"
   Zipcode: "12345"
}

テーブルの OPTIONS 句で teiid_mongo:MERGE 拡張プロパティーを使用することで、MongoDB のストレージを単一コレクションに強化できます。

    CREATE FOREIGN TABLE  Customer (
        CustomerId integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE Address (
        CustomerId integer PRIMARY KEY,
        Street varchar(50),
        City varchar(25),
        State varchar(25),
        Zipcode varchar(6),
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId)
     ) OPTIONS(UPDATABLE 'TRUE', "teiid_mongo:MERGE" 'Customer');

これにより、以下のように MongoDB で単一のコレクションが生成されます。

Customer
{
  _id: 1,
  FirstName: "John",
  LastName: "Doe",
  Address:
     {
        Street: "123 Lane",
        City: "New York",
        State: "NY",
        Zipcode: "12345"
     }
}

上記の両方のテーブルは、SQL コマンドで JOIN 句を使用してクエリーできる単一のコレクションにマージされます。この場合、子/追加レコードが存在すると、「teiid_mongo:MERGE" extension property is right choice」という親テーブルからは意味がありません。

注記

子テーブルに定義されている Foreign キーは、親テーブルと子テーブルの両方で Primary Keys を参照し、1-2-One 関係を形成する必要があります。

ONE-2-MANY マッピング。

通常、この関係には 2 つ以上のテーブルが含まれる可能性があります。MANY side が単一のテーブルのみに関連付けられている場合は、テーブルで teiid_mongo:MERGE プロパティーを使用し、ONE を親として定義します。複数のテーブルに関連付けられている場合は、teiid_mongo:EMBEDDABLE を使用します。

たとえば、仮想データベースを以下の DDL のように定義すると、以下のようになります。

    CREATE FOREIGN TABLE  Customer (
        CustomerId integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE  Order (
        OrderID integer PRIMARY KEY,
        CustomerId integer,
        OrderDate date,
        Status integer,
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId)
    ) OPTIONS(UPDATABLE 'TRUE');

その後、1 人の顧客には MANY Orders を指定できます。MongoDB ドキュメントの保存方法を定義するオプションは 2 つあります。スキーマの場合、カスタマーテーブルの CustomerId は Order テーブル（順不同の目的でのみ使用されるカスタマー情報）でのみ参照され、使用できます。

    CREATE FOREIGN TABLE  Customer (
        CustomerId integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE  Order (
        OrderID integer PRIMARY KEY,
        CustomerId integer,
        OrderDate date,
        Status integer,
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId)
    ) OPTIONS(UPDATABLE 'TRUE', "teiid_mongo:MERGE" 'Customer');

これは、以下のようなカスタマーテーブルの単一のドキュメントを生成します。

{
  _id: 1,
  FirstName: "John",
  LastName: "Doe",
  Order:
  [
     {
       _id: 100,
        OrderDate: ISODate("2000-01-01T06:00:00Z")
        Status: 2
     },
     {
       _id: 101,
        OrderDate: ISODate("2001-03-06T06:00:00Z")
        Status: 5
     }
     ...
   ]
}

Customer テーブルが Order テーブル以外のテーブルで参照される場合は、「teiid_mongo:EMBEDDABLE」プロパティーを使用します。

    CREATE FOREIGN TABLE Customer (
        CustomerId integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE', "teiid_mongo:EMBEDDABLE" 'TRUE');

    CREATE FOREIGN TABLE Order (
        OrderID integer PRIMARY KEY,
        CustomerId integer,
        OrderDate date,
        Status integer,
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE Comments (
        CommentID integer PRIMARY KEY,
        CustomerId integer,
        Comment varchar(140),
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId)
    ) OPTIONS(UPDATABLE 'TRUE');

これにより、MongoDB に 3 つの異なるコレクションが作成されます。

Customer
{
  _id: 1,
  FirstName: "John",
  LastName: "Doe"
}

Order
{
  _id: 100,
  CustomerId: 1,
  OrderDate: ISODate("2000-01-01T06:00:00Z")
  Status: 2
  Customer:
   {
     FirstName: "John",
     LastName: "Doe"
   }
}

Comment
{
  _id: 12,
  CustomerId: 1,
  Comment: "This works!!!"
  Customer:
   {
     FirstName: "John",
     LastName: "Doe"
   }
}

ここで見ると、カスタマーテーブルのコンテンツは参照先の他のテーブルのデータと共に組み込まれています。これにより、これらの埋め込みドキュメントが複数 MongoDB トランスレーターで自動的に管理される重複したデータが作成されます。

注記

すべてのコピーを更新する操作が複数あるため、「teiid_mongo:EMBEDDABLE」プロパティーでテーブルに対して生成される SELECT、INSERT、DELETE 操作はすべてアトミックです。MongoDB にはトランザクションがないため、Data Virtualization は今後のリリースで TEIID-2957 でトランザクションフレームワークを自動的に補正する予定です。

MANY-2-ONE マッピング

これは ONE-2-MANY と同じです。関係を定義するため上記を参照してください。

注記

親テーブルには、複数の「組み込み」と、その中に「マージ」ドキュメントを含めることができ、1 つ以上のドキュメントに限定されません。ただし、MongoDB ではドキュメントサイズが制限されていると 16 MB を超える可能性があることに注意してください。

MANY-2-MANY マッピング。

これは、「teiid_mongo:MERGE」および「teiid_mongo:EMBEDDABLE」プロパティーの組み合わせでマッピングすることもできます（特に）。たとえば DDL は次のようになります。

    CREATE FOREIGN TABLE Order (
        OrderID integer PRIMARY KEY,
        OrderDate date,
        Status integer
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE OrderDetail (
        OrderID integer,
        ProductID integer,
        PRIMARY KEY (OrderID,ProductID),
        FOREIGN KEY (OrderID) REFERENCES Order (OrderID),
        FOREIGN KEY (ProductID) REFERENCES Product (ProductID)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE Products (
       ProductID integer PRIMARY KEY,
       ProductName varchar(40)
    ) OPTIONS(UPDATABLE 'TRUE');

以下のような DDL を変更します。

    CREATE FOREIGN TABLE Order (
        OrderID integer PRIMARY KEY,
        OrderDate date,
        Status integer
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE OrderDetail (
        OrderID integer,
        ProductID integer,
        PRIMARY KEY (OrderID,ProductID),
        FOREIGN KEY (OrderID) REFERENCES Order (OrderID),
        FOREIGN KEY (ProductID) REFERENCES Product (ProductID)
    ) OPTIONS(UPDATABLE 'TRUE', "teiid_mongo:MERGE" 'Order');

    CREATE FOREIGN TABLE Products (
       ProductID integer PRIMARY KEY,
       ProductName varchar(40)
    ) OPTIONS(UPDATABLE 'TRUE',  "teiid_mongo:EMBEDDABLE" 'TRUE');

これにより、以下のようなドキュメントが生成されます。

{
   _id : 10248,
   OrderDate : ISODate("1996-07-04T05:00:00Z"),
   Status : 5
   OrderDetails : [
     {
       _id : {
               OrderID : 10248,
               ProductID : 11
               Products : {
                  ProductID: 11
                  ProductName: "Hammer"
               }
       }
     },
     {
       _id : {
         OrderID : 10248,
         ProductID : 14
         Products : {
             ProductID: 14
             ProductName: "Screw Driver"
         }
       }
     }
   ]
}

Products
{
    {
      ProductID: 11
      ProductName: "Hammer"
    }
    {
      ProductID: 14
      ProductName: "Screw Driver"
    }
}

制限事項

MongoDB では、ネストされたアレイを処理する機能が制限されているため、ドキュメントのネストされた埋め込みは制限されています。複数のレベルで「EMBEDDABLE」プロパティーをネストすることは OK ですが、MERGE を持つ 2 つ以上のレベルは推奨されません。また、1 行にドキュメントサイズ 16 MB を超過しないように注意してください。そのため、ディープネストは推奨されません。
関連するテーブル間で JOINS（「EMBEDDABLE」または「MERGE」プロパティーのいずれかを使用する必要があります）。それ以外の場合は、クエリーがエラーが発生します。Data Virtualization が正しく計画および JOINS と連携するようにするには、2 つのテーブルが相互に埋め込まれていない場合は、関係を表す Foreign キーで allow-joins=false プロパティーを使用します。以下に例を示します。

    CREATE FOREIGN TABLE  Customer (
        CustomerId integer PRIMARY KEY,
        FirstName varchar(25),
        LastName varchar(25)
    ) OPTIONS(UPDATABLE 'TRUE');

    CREATE FOREIGN TABLE  Order (
        OrderID integer PRIMARY KEY,
        CustomerId integer,
        OrderDate date,
        Status integer,
        FOREIGN KEY (CustomerId) REFERENCES Customer (CustomerId) OPTIONS (allow-join 'FALSE')
    ) OPTIONS(UPDATABLE 'TRUE');

上記の例では、Data Virtualization は 2 つのコレクションを作成しますが、ユーザーにとって以下のようなクエリーが発行されると、

  SELECT OrderID, LastName FROM Order JOIN Customer ON Order.CustomerId = Customer.CustomerId;

上記のプロパティーがないと、JOIN 処理がエラーになる代わりに、Data Virtualization エンジンでエラーが発生します。

上記のプロパティーを使用し、MongoDB ドキュメント構造を慎重に設計する場合、Data Virtualization トランスレーターは、コロケーションに基づいてデータをインテリジェントな場所に照合し、クエリー中にデータを活用できます。

地理空間関数

MongoDB トランスレーターを使用すると、データが MongoDB ドキュメントの GeoJSon 形式に保存される際に、「WHERE」句で地理空間クエリー演算子を使用できます。以下の関数を利用できます。

CREATE FOREIGN FUNCTION geoIntersects (columnRef string,  type string, coordinates double[][]) RETURNS boolean;
CREATE FOREIGN FUNCTION geoWithin (ccolumnRef string,  type string, coordinates double[][]) RETURNS boolean;
CREATE FOREIGN FUNCTION near (ccolumnRef string,  coordinates double[], maxdistance integer) RETURNS boolean;
CREATE FOREIGN FUNCTION nearSphere (ccolumnRef string, coordinates double[], maxdistance integer) RETURNS boolean;
CREATE FOREIGN FUNCTION geoPolygonIntersects (ref string, north double, east double, west double, south double) RETURNS boolean;
CREATE FOREIGN FUNCTION geoPolygonWithin (ref string, north double, east double, west double, south double) RETURNS boolean;

サンプルクエリーは以下のようになります。

SELECT loc FROM maps where mongo.geoWithin(loc, 'LineString', ((cast(1.0 as double), cast(2.0 as double)), (cast(1.0 as double), cast(2.0 as double))))

ビルトインの Geometry タイプを使用する同じ関数（前述の一覧の関数バージョンは非推奨となり、今後のバージョンで削除されます）。

CREATE FOREIGN FUNCTION geoIntersects (columnRef string,  geo geometry) RETURNS boolean;
CREATE FOREIGN FUNCTION geoWithin (ccolumnRef string,  geo geometry) RETURNS boolean;
CREATE FOREIGN FUNCTION near (ccolumnRef string, geo geometry, maxdistance integer) RETURNS boolean;
CREATE FOREIGN FUNCTION nearSphere (ccolumnRef string, geo geometry, maxdistance integer) RETURNS boolean;
CREATE FOREIGN FUNCTION geoPolygonIntersects (ref string, geo geometry) RETURNS boolean;
CREATE FOREIGN FUNCTION geoPolygonWithin (ref string, geo geometry) RETURNS boolean;

サンプルクエリーは以下のようになります。

SELECT loc FROM maps where mongo.geoWithin(loc, ST_GeomFromGeoJSON('{"coordinates":[[1,2],[3,4]],"type":"Polygon"}'))

Data Virtualization の Geo Spatial 関数ライブラリーでは、「st_geom..」メソッドが複数あります。

機能

MongoDB トランスレーターは、MongoDB 集約フレームワーク上に設計されています。集約フレームワークの MongoDB バージョンを使用する必要があります。SELECT クエリーとは別に、MongoDB トランスレーターは INSERT、UPDATE、DELETE クエリーでも機能します。

MongoDB トランスレーターは以下の機能で使用できます。

Grouping.
マッチング。
並び替え。
フィルタリング。
制限。
GridFS に保存されている LOB の使用。
複合プライマリーおよび外部キー。

ネイティブクエリー

MongoDB ソース手順は、teiid_rel:native-query エクステンションを使用して作成できます。詳細は「 Translators でパラメーター化 可能なネイティブクエリー 」を参照してください。この手順では、ARRAYTABLE や同様の機能を使用する必要なく、クエリーが事前に決定され、結果列タイプが認識されているという利点があります。

直接クエリーの手順

セキュリティーリスクにより、ソースに対してコマンドを実行できるセキュリティーリスクがあるため、この機能はデフォルトではオフになっています。直接クエリー手順を有効にするには、SupportsDirectQueryProcedure と呼ばれる実行プロパティーを true に設定します。詳細は、9章翻訳者 の「 実行プロパティーの上書き」を 参照してください。

デフォルトでは、クエリーを直接実行する手順の名前は native と呼ばれます。デフォルト名を変更する方法は、9章翻訳者 の「 実行プロパティーの上書き」を 参照してください。

MongoDB トランスレーターは、Data Virtualization の解析または解決を行わずに、アドホックの集約クエリーをソースに対して直接実行する手順を提供します。この手順の結果のメタデータは Data Virtualization には認識されないため、アレイの場所 1(1)に単一の Blob を含むオブジェクトアレイとして返されます。この Blob には JSON ドキュメントが含まれます。XMLTABLE は、クライアントアプリケーションが使用できるように表形式の出力を使用できます。

MongoDB Direct Query の例

    select x.* from TABLE(call native('city;{$match:{"city":"FREEDOM"}}')) t,
          xmltable('/city' PASSING JSONTOXML('city', cast(array_get(t.tuple, 1) as BLOB)) COLUMNS city string, state string) x

上記の例では、「city」と呼ばれるコレクションは、「FREEDOM」に一致するフィルターで検索され、「ネイティブ」の手順を使用して、ネストされたテーブル機能を使用して出力が XMLTABLE コンストラクトに渡され、この手順からの出力が JSONTOXML 関数に送信され、XML の結果が表形式で公開されます。

直接クエリーは形式でなければなりません。

     "collectionName;{$pipeline instr}+"

Data Virtualization 8.10 から、MongoDB トランスレーターは remove、drop、createIndex などの Shell タイプの java スクリプトコマンドを実行することもできます。この場合は、コマンドの形式にする必要があります。

     "$ShellCmd;collectionName;operationName;{$instr}+"

たとえば、以下のようになります。

   "$ShellCmd;MyTable;remove;{ qty: { $gt: 20 }}"

9.8. MongoDB Translator

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links