MongoDB への接続を追加

1. アプリケーションコンソールで、接続ページに移動します。
2. 接続の追加パネルで、追加したい接続のアイコンを選択します。
3. MongoDB アイコンが利用できない場合は、Add More アイコンをクリックしてCData サイトからMongoDB コネクタをダウンロードおよびインストールします。

必須プロパティについては、設定タブを参照してください。

通常必須ではない接続プロパティについては、高度な設定タブを参照してください。

MongoDB への接続

次の接続プロパティを設定し、単一のMongoDB インスタンスに接続します。

• Server：MongoDB インスタンスが実行されているサーバーの名前またはアドレスに設定。ポートはここで指定できます。またはPort で指定します。
• Database：読み書きするデータベースに設定。

DNS シードリストを使用してMongoDB に接続

• Server："mongodb+srv://"" + MongoDB インスタンスが実行されているサーバーの名前に設定。ポートはここで指定できます。またはPort で指定します。
• Database：読み書きするデータベースに設定。
• DNSServer：必要なDNS エントリを解決できるDNSServer のホスト名に設定。

レプリカセットへの接続

レプリカセットに接続するには、前述の接続プロパティに加えて、 次の設定を行います。

• ReplicaSet：アドレスとポートで指定されたレプリカセット内のセカンダリサーバーのカンマ区切りリストに設定。
• SlaveOK：セカンダリ（スレーブ）サーバーから読み出す場合は、これをtrue に設定。
• ReadPreference：これを設定すると、Sync App のセカンダリサーバーからの読み出し方法が微調整されます。

セキュアなMongoDB への接続

UseSSL を設定すると、接続時にSSL/TLS 暗号化をネゴシエートできます。

MongoDB 接続の認証

サポートされているAuthScheme 認証タイプ（MONGODB-CR、SCRAM-SHA-1、SCRAM-SHA-256、PLAIN、GSSAPI）は、チャレンジレスポンス認証とLDAP です。

チャレンジレスポンス

チャレンジレスポンス認証では、User とPassword プロパティは、MongoDB データベースに格納されているユーザー名とパスワードに対応しています。1つのデータベースのデータに接続し、別のデータベースを認証する必要がある場合は、Database とAuthDatabase の両方を設定します。

LDAP

LDAP 認証を使用するには、AuthDatabase を"$external" に設定し、AuthScheme をPLAIN に設定します。この値はSASL PLAIN メカニズムを指定します。このメカニズムは視覚情報をプレーンテキストで送信するため、信頼できないネットワークではTLS/SSL なしでは使用できません。

X.509 証明書

X.509 証明書認証を使用するには、AuthScheme をX509 に設定します。

Amazon DocumentDB クラスターへの接続

Amazon DocumentDB に接続する前に、まずAmazon DocumentDB クラスターと、mongo シェルを含むEC2 インスタンスが実行されていることを確認する必要があります。

次に、EC2 インスタンスへのSSH トンネルを以下のように設定します。

1. AWS 管理コンソールから、［サービス］->［データベース］->［Amazon DocumentDB］を選択します。DocumentDB 管理ページから、［クラスター］を選択して、クラスターをクリックします。
2. ［接続］セクションで、サンプル接続文字列にある--host の値とそのポートに注意してください。
3. ［サービス］->［Compute］->［EC2］に移動します。［実行中のインスタンス］を選択します。
4. インスタンスを選択して、［接続］ボタンをクリックします。
5. ［Example］セクションで、<ami_username>@<Public DNS> の形式で示される、インスタンスとユーザーを識別する値に注意してください。
6. お好みのSSH クライアントで、EC2インスタンスの［接続］ページのHost Name（username@publicDNS）とPort22 を使用して、EC2 インスタンスへの接続を確立します。
7. 認証用に、EC2インスタンスの秘密鍵ファイルを指定します（Putty ではキーを.pem から.ppk に変換する必要があります）。
8. DocumentDB クラスターページのポートとホスト名を使用して、SSH トンネルを構成します。
9. EC2仮想マシンに接続を確立します。

DocumentDB クラスターに接続するには、以下を指定します。

• Server：SSH トンネルをホストしているマシン名に設定。
• Port：SSH トンネルがホストされているポートに設定。
• User：DocumentDB クラスターのプロビジョニングに使用するマスターユーザー名に設定。
• Password：DocumentDB クラスターのプロビジョニング時に設定したマスターパスワードに設定。
• UseSSL：true に設定。
• UseFindAPI：true に設定。

MongoDB API を使用したCosmosDB への接続

MongoDB API を使ってCosmos DB アカウントに接続するために必要な接続文字列を取得するには、Azure Portal にログインして［Azure Cosmos DB］を選択し、自分のアカウントを選択します。［Settings］セクションで、［Connection String］をクリックして次の値を設定します。

• Server：Host 値（アカウント用にプロビジョニングされたサーバーのFQDN）に設定。ポートもここで指定できます。またはPort で指定します。
• Port：ポートに設定。
• Database：読み書きするデータベースに設定。
• User：データベースユーザーに設定。
• Password：ユーザーのパスワードに設定。

Atlas、ObjectRocket、または別のDBaaS プロバイダーに接続する場合は、通常、［接続の確立］に記載されている手順にいくつかのバリエーションがあります。次のセクションでは、いくつかの一般的なサービスに必要な接続プロパティを取得する方法について説明します。

Atlas

MongoDB Atlas には、MongoDB ユーザーまたはLDAP ユーザーで認証できます。次のセクションでは、Atlas 接続文字列をSync App 接続プロパティにマッピングする方法を説明します。Atlas 接続文字列を取得する方法は次のとおりです。

1. Clusters ビューで、接続するクラスタのConnect をクリックします。
2. Connect Your Application をクリックします。
3. いずれかのドライバーオプションを選択すると、接続文字列が表示されます。

前提条件

MongoDB ユーザーの作成および／またはLDAP の設定に加えて、Atlas プロジェクトのホワイトリストに、Sync App が接続しているマシンのIP アドレスが含まれている必要があります。ホワイトリストにIP アドレスを追加するには、［Clusters］ビューで［Security］タブを選択し、［IP Whitelist］->［Add IP Address］をクリックします。

MongoDB ユーザー資格情報

次は、MongoDB ユーザー資格情報を提供する接続文字列の例です。

mongodb://USERNAME:[email protected]:27017,cluster0-shard-00-01.mongodb.net:27017,cluster0-shard-00-02.mongodb.net:27017/test?ssl=true&replicaSet=Cluster0-shard-0&authSource=admin

• AuthScheme：MongoDB バージョン3.0、3.2、3.4、および3.6 に対応するSCRAM-SHA-1。
• Server：レプリカセットの最初のサーバー。あるいは、プライマリまたはセカンダリサーバーを指定できます（Sync App はServer とReplicaSet 内のサーバーをクエリしてプライマリを検索します）。
  

  cluster0-shard-00-00.mongodb.net

• Port：サーバーが稼働しているポート（デフォルトは27017）。
• ReplicaSet：レプリカセット内の他のサーバー。Server とReplicaSet は、MongoDB レプリカセット内のすべてのインスタンスを一緒に指定します。ReplicaSet にサーバー名およびポートを両方指定します。
  

  mycluster0-shard-00-01.mongodb.net:27017,mycluster0-shard-00-02.mongodb.net:27017

• SlaveOK：レプリカセット内のセカンダリ（スレーブ）サーバーからの読み取りを許可する場合は、true。
• AuthDatabase：MongoDB Atlas に接続する場合は、"admin"。Atlas のすべてのMongoDB ユーザーは、管理データベース、すなわち認証データベースに関連付けられています。
• Database：読み書きするデータベース。

• User：MongoDB プロジェクトに追加したMongoDB ユーザーのユーザー名。

• Password：MongoDB ユーザーのパスワード。

• UseSSL：true。Atlas はTLS / SSLを必要とします。

LDAP

次のリストは、LDAP ユーザーで認証するためのMongoDB Atlas の要件を示しています。 以下はMongo クライアントに接続するためのコマンド例です。

mongo "mongodb://cluster0-shard-00-00.mongodb.net:27017,cluster0-shard-00-01.mongodb.net:27017,cluster0-shard-00-02.mongodb.net:27017/test?ssl=true&replicaSet=Cluster0-shard-0&authSource=$external" --authenticationMechanism PLAIN --username cn=rob,cn=Users,dc=atlas-ldaps-01,dc=myteam,dc=com 

• Server：レプリカセットの最初のサーバー。または、別のプライマリまたはセカンダリサーバーを指定できます（Sync App はServer とReplicaSet 内のサーバーをクエリしてプライマリを検索します）。 次に例を示します。
  

  cluster0-shard-00-00.mongodb.net

• Port：サーバーが稼働しているポート（デフォルトは27017）。
• ReplicaSet：レプリカセット内の他のサーバー。Server とReplicaSet は、MongoDB レプリカセット内のすべてのインスタンスを一緒に指定します。 以下に値の例を示します。
  

  mycluster0-shard-00-01.mongodb.net:27017,mycluster0-shard-00-02.mongodb.net:27017

• SlaveOK：レプリカセット内のセカンダリ（スレーブ）サーバーからの読み取りを許可する場合は、true。

• AuthScheme：LDAP 認証のPLAIN。

• Database：読み書きするデータベース。

• AuthDatabase：LDAP ユーザーで認証する場合は、"$external"。

• User：Atlas ユーザー名としてLDAP サーバーにあるユーザーの完全な識別名（DN）。次に例を示します。
  

  cn=rob,cn=Users,dc=atlas-ldaps-01,dc=myteam,dc=com

• Password：LDAP ユーザーのパスワード。

• UseSSL：true。Atlas はTLS / SSLを必要とします。

ObjectRocket

ObjectRocket に接続するには、データベースユーザーの資格情報を使用して認証します。コントロールパネルから必要な接続プロパティを取得できます。［インスタンス］ページでインスタンスを選択し、［接続］メニューを選択してMongoDB 接続文字列を表示します。

前提条件

データベースにユーザーを追加することに加えて、Sync App が接続しているマシンのIP アドレスへのアクセスも許可する必要があります。これを設定するには、［インスタンス］ページでインスタンスを選択し、［Add ACL］をクリックします。

MongoDB ユーザー

mongodb://YOUR_USERNAME:[email protected]:52826,abc123-d4-2.mongo.objectrocket.com:52826,abc123-d4-1.mongo.objectrocket.com:52826/YOUR_DATABASE_NAME?replicaSet=89c04c5db2cf403097d8f2e8ca871a1c

• Server：レプリカセットの最初のサーバー。サーバー名を取得するには、［レプリカセット］をクリックします。または、別のプライマリまたはセカンダリサーバーを指定できます（Sync App はServer とReplicaSet 内のサーバーをクエリしてプライマリを検索します）。
  

  abc123-d4-0.mongo.objectrocket.com

• Port：サーバーが稼働しているポート（デフォルトは27017）。
• ReplicaSet：レプリカセット内の他のサーバー。Server とReplicaSet は、MongoDB レプリカセット内のすべてのインスタンスを一緒に指定します。 以下に値の例を示します。
  

  abc123-d4-2.mongo.objectrocket.com:52826,abc123-d4-1.mongo.objectrocket.com:52826

• Database：読み書きするデータベース。これは、接続しているユーザーの認証データベースでもあることに注意してください。データベースユーザーは、ObjectRocket のデータベース外の他のデータベースと対話することはできません。
• User：Database に定義したMongoDB ユーザーのユーザー名。
• Password：データベースユーザーのパスワード。
• UseSSL：TLS / SSL を有効にする場合は、true。

MongoDB はスキーマレスなドキュメントデータベースで、高いパフォーマンス、使用性、およびスケーラビリティを提供します。これらの機能は、必ずしもSQL-92 のような標準準拠のクエリ言語と互換しないわけではありません。このセクションでは、Sync App が複数のやり方によって、リレーショナルSQL とドキュメントデータベースのギャップの橋渡しをいかに行うかを説明します。

テーブルとしてのMongoDB オブジェクトの操作

Sync App では、スキーマレスなMongoDB オブジェクトをリレーショナルテーブルにモデル化し、SQL クエリをMongoDB クエリに読み替えることで、要求されたデータを取得します。 さまざまなMongoDB 操作がSQL としてどのように表されるかの詳細については、クエリマッピング を参照してください。

スキーマの自動検出

自動スキーマ検出 スキームでは、設定された行数のオブジェクトをスキャンすることで、自動的にMongoDB 内のデータ型を見つけます。MongoDB コレクションのリレーショナル表現をコントロールするためにRowScanDepth、FlattenArrays、およびFlattenObjects を使うことができます。スキーマに結びついていない自由形式クエリ を記述することもできます。

Sync App は、コレクション内のMongoDB ドキュメントをサンプルとして調べ、リレーショナルスキーマを提案します。RowScanDepth プロパティを使って、Sync App がスキャンするドキュメント数を設定することができます。検出プロセスで特定されるカラムはFlattenArrays およびFlattenObjects プロパティに依存します。

オブジェクトのフラット化

FlattenObjects が設定されている場合、すべてのネストされたオブジェクトは連続したカラムにフラット化されます。例えば、次のドキュメントを考えましょう。

{
  id: 12,
  name: "Lohia Manufacturers Inc.",
  address: {street: "Main Street", city: "Chapel Hill", state: "NC"},
  offices: ["Chapel Hill", "London", "New York"],
  annual_revenue: 35,600,000
}

FlattenObjects が設定されていない場合、address.street、address.city、およびaddress.state カラムは別々にはなりません。文字列型の住所カラムは一つのオブジェクトとして表されます。値は次のようになります {street:"Main Street", city:"Chapel Hill", state:"NC"}。JSON アグリゲートの詳細についてはJSON 関数 を参照してください。

配列のフラット化

FlattenArrays プロパティは配列の値をフラット化してそれぞれのカラムとするために使われます。これは次の例のように短い配列の場合にのみ推奨されます。

"coord": [ -73.856077, 40.848447 ]

アンバウンドの配列をそのままにしておき、必要な際にJSON 関数 を使ってデータを取り出すことをお勧めします。

自動スキーマ検出 の説明にあるとおり、直感的なテーブルスキーマは非構造化MongoDB データへのSQL アクセスを可能にします。JSON 関数 は標準のJSON 関数を使ってMongoDB データをサマライズし、あらゆるネスト構造から値を抽出できます。 カスタムスキーマ定義 では静的なテーブルを定義でき、データのリレーショナルビューでの緻密な制御を可能にします。例えば、parent/child テーブルやfact/dimension テーブルを定義するスキーマを記述することができます。 しかし、これらのスキーマに限定されません。

接続後は、どんなネストされた構造でもデータをフラット化せずにクエリできますFlattenArrays やFlattenObjects でアクセスできるあらゆるリレーションへは、アドホックなSQL クエリを使ってもアクセスが可能です。

次のRestaurant データセットからのサンプルドキュメントを考えてみましょう。

 
{
  "address": {
    "building": "1007",
    "coord": [
      -73.856077,
      40.848447
    ],
    "street": "Morris Park Ave",
    "zipcode": "10462"
  },
  "borough": "Bronx",
  "cuisine": "Bakery",
  "grades": [
    {
      "grade": "A",
      "score": 2,
      "date": {
        "$date": "1393804800000"
      }
    },
    {
      "date": {
        "$date": "1378857600000"
      },
      "grade": "B",
      "score": 6
    },
    {
      "score": 10,
      "date": {
        "$date": "1358985600000"
      },
      "grade": "C"
    }
  ],
  "name": "Morris Park Bake Shop",
  "restaurant_id": "30075445"
} 

SELECT [address.building], [grades.1.grade] FROM restaurants WHERE restaurant_id = '30075445'

ドキュメントの配列を、個別のテーブルのように取得することが可能です。例えば、restaurants コレクションから次のJSON 構造を取得します。

{
  "_id" : ObjectId("568c37b748ddf53c5ed98932"),
  "address" : {
    "building" : "1007",
    "coord" : [-73.856077, 40.848447],
    "street" : "Morris Park Ave",
    "zipcode" : "10462"
  },
  "borough" : "Bronx",
  "cuisine" : "Bakery",
  "grades" : [{
      "date" : ISODate("2014-03-03T00:00:00Z"),
      "grade" : "A",
      "score" : 2
    }, {
      "date" : ISODate("2013-09-11T00:00:00Z"),
      "grade" : "A",
      "score" : 6
    }, {
      "date" : ISODate("2013-01-24T00:00:00Z"),
      "grade" : "A",
      "score" : 10
    }, {
      "date" : ISODate("2011-11-23T00:00:00Z"),
      "grade" : "A",
      "score" : 9
    }, {
      "date" : ISODate("2011-03-10T00:00:00Z"),
      "grade" : "B",
      "score" : 14
    }],
  "name" : "Morris Park Bake Shop",
  "restaurant_id" : "30075445"
}

SELECT * FROM [restaurants.grades]

ベースのrestaurants テーブルからの情報も含めたい場合は、結合を使って実現できます。フラット化された配列はルートドキュメントでのみ結合できます。Sync App では、結合の左部分を、垂直にフラット化したい配列ドキュメントだと判断します。SupportEnhancedSQL を無効にして、ネストされたMongoDB ドキュメントを結合します。このタイプのクエリはMongoDB API 経由でサポートされています。

SELECT [restaurants].[restaurant_id], [restaurants.grades].* FROM [restaurants.grades] JOIN [restaurants] WHERE [restaurants].name = 'Morris Park Bake Shop'

他の配列の中にある配列を対象としたクエリを作成することも可能です。

以下がInventory コレクションの例です。

{
	"_id": {
		"$oid": "xxxxxxxxxxxxxxxxxxxxxx"
	},
	"Company Branch": "Main Branch",
	"ItemList": [
		{
			"item": "journal",
			"instock": [
				{
					"warehouse": "A",
					"qty": 15
				},
				{
					"warehouse": "B",
					"qty": 45
				}
			]
		},
		{
			"item": "paper",
			"instock": [
				{
					"warehouse": "A",
					"qty": 50
				},
				{
					"warehouse": "B",
					"qty": 5
				}
			]
		}
	]
}

Insert data into the nested arrays using the syntax of <parent array>.<index>.<child array>, as follows:

INSERT INTO [Inventory.ItemList] (p_id, item, [instock.0.warehouse], [instock.0.qty], [instock.0.price]) VALUES ('xxxxxxxxxxxxxxxxxxxxxx', 'NoteBook', 'B', 20, '5$')

The Inventory collection after executing the INSERT statement:

{
	"_id": {
		"$oid": "xxxxxxxxxxxxxxxxxxxxxx"
	},
	"Company Branch": "Main Branch",
	"ItemList": [
		{
			"item": "journal",
			"instock": [
				{
					"warehouse": "A",
					"qty": 15
				},
				{
					"warehouse": "B",
					"qty": 45
				}
			]
		},
		{
			"item": "paper",
			"instock": [
				{
					"warehouse": "A",
					"qty": 50
				},
				{
					"warehouse": "B",
					"qty": 5
				}
			]
		},
		{
			"item": "NoteBook",
			"instock": [
				{
					"warehouse": "B",
					"qty": 20,
					"price": "5$"
				}
			]
		}
	]
}

Sync App では、JSON ストラクチャーをカラム値として返すことができます。Sync App を使って、これらのJSON ストラクチャーにおいて標準SQL 関数を使用できます。このセクションの例では、次の配列を使用します。

[
     { "grade": "A", "score": 2 },
     { "grade": "A", "score": 6 },
     { "grade": "A", "score": 10 },
     { "grade": "A", "score": 9 },
     { "grade": "B", "score": 14 }
]

JSON_EXTRACT

SELECT Name, JSON_EXTRACT(grades,'[0].grade') AS Grade, JSON_EXTRACT(grades,'[0].score') AS Score FROM Students;

JSON_COUNT

SELECT Name, JSON_COUNT(grades,'[x]') AS NumberOfGrades FROM Students;

JSON_SUM

SELECT Name, JSON_SUM(score,'[x].score') AS TotalScore FROM Students;

JSON_MIN

SELECT Name, JSON_MIN(score,'[x].score') AS LowestScore FROM Students;

JSON_MAX

SELECT Name, JSON_MAX(score,'[x].score') AS HighestScore FROM Students;

DOCUMENT

DOCUMENT 関数はすべてのドキュメントをJSON 文字列として取得する場合に用いられます。例として、次のクエリとその結果をご覧ください。

SELECT DOCUMENT(*) FROM Customers;

{ "id": 12, "name": "Lohia Manufacturers Inc.", "address": { "street": "Main Street", "city": "Chapel Hill", "state": "NC"}, "offices": [ "Chapel Hill", "London", "New York" ], "annual_revenue": 35,600,000 }

Sync App は、SQL クエリを対応するMongoDB クエリにマッピングします。ここではトランスフォーメーションの詳細は説明しませんが、いくつか代表的なものを説明します。Sync App は、Aggregation Framework などのMongoDB の機能の良いところを使って望まれる結果を出します。

SELECT クエリ

SELECT * FROM Users

db.users.find()

SELECT user_id, status 
FROM Users

db.users.find(
  {}, 
  { user_id: 1, status: 1, _id: 0 }
)

SELECT * 
FROM Users 
WHERE status = 'A'

db.users.find( 
  { status: "A" }
)

SELECT * 
FROM Users 
WHERE status = 'A' OR age=50

db.users.find(
  { $or: [ { status: "A" }, 
           { age: 50 } ] }
)

SELECT * 
FROM Users 
WHERE name LIKE 'A%'

db.users.find(
  {name: /^a/}
)

SELECT * FROM Users 
WHERE status = 'A'
ORDER BY user_id ASC

db.users.find( { status: "A" }.sort( { user_id: 1 } )

SELECT * 
FROM Users 
WHERE status = 'A' 
ORDER BY user_id DESC

db.users.find( {status: "A" }.sort( {user_id: -1} )

Aggregate クエリ

SELECT Count(*) As Count 
FROM Orders

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: null, 
      count: { $sum: 1 } 
    } 
  } 
] )

SELECT Sum(price) As Total 
FROM Orders

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: null, 
      total: { $sum: "$price" } 
    }
  } 
] )

SELECT cust_id, Sum(price) As total 
FROM Orders 
GROUP BY cust_id 
ORDER BY total

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: "$cust_id", 
      total: { $sum: "$price" } 
    } 
  } ,
  { $sort: {total: 1 } }
] )

SELECT cust_id, ord_date, Sum(price) As total 
FROM Orders 
GROUP BY cust_id, ord_date 
HAVING total > 250

db.orders.aggregate( [ 
  { 
    $group: { 
      _id: { 
        cust_id: "$cust_id", 
        ord_date: { 
          month: { $month: "$ord_date" }, 
          day: { $dayOfMonth: "$ord_date" }, 
          year: { $year: "$ord_date"} 
        } 
      }, 
      total: { $sum: "$price" } 
    }
  }, 
  { $match: { total: { $gt: 250 } } } 
] )

INSERT ステートメント

INSERT INTO users (user_id, age, status, [address.city], [address.postalcode]) 
VALUES ('bcd001', 45, 'A', 'Chapel Hill', 27517)

db.users.insert( 
  { user_id: "bcd001", age: 45, status: "A", address:{ city:"Chapel Hill", postalCode:27514} }
) 

INSERT INTO t1 ("c1") VALUES (('a1', 'a2', 'a3'))

db.users.insert({"c1": ['a1', 'a2', 'a3']})

INSERT INTO t1 ("c1") VALUES (())

db.users.insert({"c1": []})

INSERT INTO t1 ("a.b.c.c1") VALUES (('a1', 'a2', 'a3'))

db.users.insert("a":{"b":{"c":{"c1":['a1','a2', 'a3']}}})

更新ステートメント

UPDATE users 
SET status = 'C', [address.postalcode] = 90210
WHERE age > 25

db.users.update( 
  { age: { $gt: 25 } }, 
  { $set: { status: "C", address.postalCode: 90210 }, 
  { multi: true }
) 

削除ステートメント

DELETE FROM users WHERE status = 'D'

db.users.remove( { status: "D" } )

自動スキーマ検出 で作成されたテーブルスキーマを、スキーマファイルに保存することで拡張できます。スキーマファイルはシンプルな形式で、変更は簡単です。

スキーマファイルの生成

GenerateSchemaFiles を"OnStart" に設定すると、接続時にすべてのテーブルのスキーマを保持します。テーブルスキーマを必要に応じて生成することもできます。GenerateSchemaFiles を"OnUse" に設定して、テーブルにSELECT クエリを実行します。

例えば、レストランのデータセットのスキーマを考えてみましょう。これはMongoDB が提供するサンプルデータです。データセットをダウンロードするには、MongoDB ガイドのはじめにの説明に従います。

コレクションからのサンプルドキュメントは以下のとおりです。

{
  "address":{
    "building":"461",
      "coord":[
        -74.138492,
        40.631136
      ],
      "street":"Port Richmond Ave",
      "zipcode":"10302"
   },
   "borough":"Staten Island",
   "cuisine":"Other",
   "name":"Indian Oven",
   "restaurant_id":"50018994"
}

MongoDB のレストランデータセットのインポート

Mongoimport ユーティリティを使ってデータセットをインポートできます。

mongoimport --db test --collection restaurants --drop --file dataset.json

スキーマのカスタマイズ

GenerateSchemaFiles が設定されている場合、Sync App はLocation プロパティで指定されたフォルダ内にスキーマを格納します。生成されたスキーマでカラムの動作を変更できます。

次のスキーマは、other:bsonpath プロパティを使用して、特定のカラムのデータをコレクションのどこに取得するかを定義します。このモデルを使って、階層構造のアービトラリーレベルをフラット化することができます。

collection 属性は、パースするコレクションを指定します。collection 属性は、同じコレクションに対して複数のスキーマを使う柔軟性を与えます。collection が指定されていない場合は、filename がパースされるコレクションを決定します。

以下は、カラム定義とカラム値を抽出するためのコレクションです。カスタムスキーマ例 では、完全なスキーマを確認できます。

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">  

  <rsb:info title="StaticRestaurants" description="Custom Schema for the MongoDB restaurants data set.">  
    <!-- Column definitions -->
    <attr  name="borough"   xs:type="string" other:bsonpath="$.borough"              />
    <attr  name="cuisine"   xs:type="string" other:bsonpath="$.cuisine"              />
    <attr  name="building"  xs:type="string" other:bsonpath="$.address.building"     />
    <attr  name="street"    xs:type="string" other:bsonpath="$.address.street"       />
    <attr  name="latitude"  xs:type="double" other:bsonpath="$.address.coord.0"      />
    <attr  name="longitude" xs:type="double" other:bsonpath="$.address.coord.1"      />
  </rsb:info>  

  <rsb:set attr="collection" value="restaurants"/>

</rsb:script>

このセクションでは、GenerateSchemaFiles によって自動生成された完全なスキーマの例を示します。Location プロパティをスキーマファイルを格納するファイルディレクトリに設定します。スキーマは、以下で構成されています。

• info セクションではMongoDB オブジェクトのリレーショナルビューを可能にします。詳細はカスタムスキーマ定義 を参照してください。

• collection アトリビュートは、パースするコレクションの名前を指定します。collection アトリビュートは、同じコレクションに対して複数のスキーマを定義するために使用できます。collection が指定されていない場合は、filename がパースされるコレクションを決定します。

• GET、POST、MERGE、およびDELETE メソッドは、このテーブルに対してSELECT、INSERT、UPDATE、およびDELETE コマンドを許容します。coreExecOperation 処理は内部実装であり、そのまま独自のカスタムスキーマファイルにコピーできます。

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">  

  <rsb:info title="StaticRestaurants" description="Automatic GenerateSchemaFile">  
    <!-- Column definitions -->
    <attr  name="borough"           xs:type="string"  other:bsonpath="$.borough"          />
    <attr  name="cuisine"           xs:type="string"  other:bsonpath="$.cuisine"          />
    <attr  name="address_building"  xs:type="string"  other:bsonpath="$.address.building" />
    <attr  name="address_street"    xs:type="string"  other:bsonpath="$.address.street"   />
    <attr  name="address_coord_0"   xs:type="double"  other:bsonpath="$.address.coord.0"  />
    <attr  name="address_coord_1"   xs:type="double"  other:bsonpath="$.address.coord.1"  />
  </rsb:info>  

  <rsb:set attr="collection" value="restaurants"/>

  <rsb:script method="GET">
    <rsb:call op="coreExecOperation" out="toout">
      <rsb:push item="toout"/>
    </rsb:call>
  </rsb:script>

  <rsb:script method="POST">
    <rsb:call op="coreExecOperation" out="toout">
      <rsb:push item="toout"/>
    </rsb:call>
  </rsb:script>

  <rsb:script method="DELETE">
    <rsb:call op="coreExecOperation" out="toout">
      <rsb:push item="toout"/>
    </rsb:call>
  </rsb:script>

  <rsb:script method="MERGE">
    <rsb:call op="coreExecOperation" out="toout">
      <rsb:push item="toout"/>
    </rsb:call>
  </rsb:script>

</rsb:script>

データ型のマッピング

Sync App は、データソースの型を、スキーマで使用可能な対応するデータ型にマッピングします。以下のテーブルはこれらのマッピングを説明します。

このセクションでは、MongoDB Sync App の高度な機能を厳選して説明します。

ユーザー定義ビュー

Sync App を使用すると、事前設定されたクエリによって内容が決定されるユーザー定義ビューと呼ばれる仮想テーブルを定義できます。 このビューは、ドライバーに発行されるクエリを直接制御できない場合に有効です。 カスタムビューの作成と設定の概要については、ユーザー定義ビュー を参照してください。

SSL の設定

SSL の設定 を使用して、Sync App が証明書のネゴシエーションをどのように扱うかを調整します。さまざまな証明書形式を選択できます。 詳しくは、接続文字列オプションにあるSSLServerCert プロパティを参照してください。

ファイアウォールとプロキシ

Windows プロキシを含むファイアウォールとプロキシ に合致するようSync App を設定します。トンネル接続を設定することもできます。

クエリ処理

Sync App は、MongoDB にできるだけ多くのSELECT ステートメント処理をオフロードし、残りのクエリをクライアント側のインメモリで処理します。

詳しくはクエリ処理 を参照してください。

ログ

CData ログを調整するために使用可能な設定の概要については、ログ を参照してください。基本的なロギングでは、 次の2つの接続プロパティを設定するだけです。LogModules 接続プロパティを使用してログに記録する情報のサブセットを選択できる、 より洗練されたロギングをサポートする多数の機能があります。

SSL 設定のカスタマイズ

デフォルトでは、Sync App はサーバーの証明書をシステムの信頼できる証明書ストアと照合してSSL / TLS のネゴシエーションを試みます。

別の証明書を指定するには、利用可能なフォーマットについてSSLServerCert プロパティを参照してください。

クライアントSSL 証明書

MongoDB Sync App はクライアント証明書の設定もサポートしています。次を設定すれば、クライアント証明書を使って接続できます。

• SSLClientCert：クライアント証明書のための証明書ストア名。
• SSLClientCertType：TLS / SSL クライアント証明書を格納するキーストアの種類。
• SSLClientCertPassword：TLS / SSL クライアント証明書のパスワード。
• SSLClientCertSubject：TLS / SSL クライアント証明書のサブジェクト。

Firewall またはProxy 経由の接続

次のプロパティを設定します。

• プロキシベースのファイヤーウォールを使用するには、FirewallType、FirewallServer、およびFirewallPort を設定します。
• 接続をトンネルするには、FirewallType をTUNNEL に設定します。
• 認証するには、FirewallUser とFirewallPassword を設定します。
• SOCKS プロキシへの認証には、さらにFirewallType をSOCKS5 に設定します。

Authentication

Kerberos

SSL

SSH

Firewall

Logging

Schema

Miscellaneous

このセクションでは、本プロバイダーの接続文字列で設定可能なAuthentication プロパティの全リストを提供します。

The authentication mechanism that MongoDB will use to authenticate the connection.

解説

Accepted values are MONGODB-CR, SCRAM-SHA-1, SCRAM-SHA-256, GSSAPI, PLAIN, and NONE. The following authentication types correspond to the authentication values.

Authenticating with Challenge-Response

Generally, this property does not need to be set for this authentication type, as the Sync App uses different challenge-response mechanisms by default to authenticate a user to different versions of MongoDB.

• MongoDB 2: MongoDB 2 uses MONGODB-CR to authenticate.
• MongoDB 3.x: MongoDB 3 uses SCRAM-SHA-1 by default; new users you create in MongoDB 3 use this authentication method. However, MongoDB 3 servers will continue to use MONGODB-CR to authenticate users created in MongoDB 2.6.
• MongoDB 4.x: MongoDB 4 uses SCRAM-SHA-1 by default and does not support the deprecated MongoDB MONGODB-CR authentication mechanism.

Authenticating with LDAP

Set AuthScheme to PLAIN to use LDAP authentication. This value specifies the SASL PLAIN mechanism; note that this mechanism transmits credentials over plain-text, so it is not suitable for use without TLS/SSL on untrusted networks.

Authenticating with Kerberos

Set AuthScheme to GSSAPI to use Kerberos authentication. Additionally configure the following properties as configured for the MongoDB environment:

Authenticating with X.509 Authentication

Set AuthScheme to X509 to use X.509 certificate authentication.

MongoDB データベースをホストしているサーバーのホスト名、またはIP アドレス。

解説

MongoDB データベースをホストしているサーバーのホスト名、またはIP アドレス。If you choose to connect using DNS seed lists, set this option to "mongodb+srv://" + the name of the server your MongoDB instance is running on.

MongoDB データベースのポート。

解説

MongoDB データベースのポート。

認証で使用されるMongoDB ユーザーアカウント。

解説

このフィールドは、Password とともに、MongoDB サーバーに対して認証をするために使われます。

ユーザーの認証で使用されるパスワード。

解説

User およびPassword を一緒に使用してサーバーで認証を行います。

MongoDB データベース名。

解説

MongoDB データベース名。

このフィールドはSSL が有効化されているかどうかを設定します。

解説

このフィールドは、Sync App がサーバーとのTLS/SSL 接続をネゴシエートするかどうかを設定します。デフォルトでは、Sync App はサーバーの証明書をシステムの信頼できる証明書ストアと照合します。別の証明書を指定するには、SSLServerCert を設定します。

認証のためのMongoDB データベース名。

解説

認証のためのMongoDB データベース名。データを取得するデータベースと認証データベースが異なる場合のみ必要となります。

このプロパティを使うと、 Server および Port で設定されたサーバーに加え、複数のサーバーを指定できます。サーバー名およびポートの両方を、サーバーをカンマで区切って指定します。

解説

このプロパティを使うと、Server およびPort で設定されたサーバーに加え、レプリカセット内の他のサーバーを指定できます。ReplicaSet、Server、およびPort を使用して、レプリカセット内のすべてのサーバーを指定する必要があります。

サーバー名およびポートの両方をReplicaSet に指定します。サーバーはカンマで区切ります。次に例を示します。

Server=localhost;Port=27017;ReplicaSet=localhost:27018,localhost:27019;

プライマリサーバーを見つけるために、Sync App は、ReplicaSet 内のサーバーとServer およびPort で指定されたサーバーをクエリします。

レプリカセット内のプライマリサーバーだけが書き込み可能です。 セカンダリは、SlaveOK の設定が読み取りを許容している場合に読み取りが可能です。セカンダリにSELECT クエリを実行するストラテジーを設定するには、ReadPreference を参照してください。

Specify the DNS server when resolving MongoDB seed list.

解説

Specify the DNS server when resolving MongoDB seed list.

このセクションでは、本プロバイダーの接続文字列で設定可能なKerberos プロパティの全リストを提供します。

ユーザーの認証で使用されるKerberos キー配布センター（KDC）サービス。

解説

Kerberos のプロパティは、SPNEGO またはWindows 認証を使用する場合に使用されます。Sync App は、Kerberos KDC サービスにセッションチケットと一時セッションキーを要求します。Kerberos KDC サービスは、通常、ドメインコントローラーと同じコンピュータに置かれています。

Kerberos KDC が指定されていない場合、Sync App は、これらのプロパティを自動的に次の場所から検出しようとします。

• KRB5 Config File (krb5.ini/krb5.conf)： KRB5_CONFIG 環境変数が設定され、ファイルが存在する場合、Sync App は指定されたファイルからKDC を取得します。それ以外の場合は、OS に基づいてデフォルトのMIT ロケーションからの読み取りを試みます：C:\ProgramData\MIT\Kerberos5\krb5.ini (Windows) または/etc/krb5.conf (Linux)。
• ドメイン名およびホスト： Kerberos 領域およびKerberos KDC が別の場所から推測できなかった場合、Sync App は設定されているドメイン名およびホストからそれらを推測します。

ユーザー認証に使用されるKerberos 領域。

解説

Kerberos のプロパティは、SPNEGO またはWindows 認証を使用する場合に使用されます。Kerberos 領域は、Kerberos キー配布センター（KDC）サービスを使用してユーザーを認証するために使用されます。Kerberos 領域は、管理者が任意の文字列に設定できますが、通常はドメイン名に基づいて設定されます。

Kerberos 領域が指定されていない場合、Sync App は、これらのプロパティを自動的に次の場所から検出しようとします。

• KRB5 Config File (krb5.ini/krb5.conf)： KRB5_CONFIG 環境変数が設定され、ファイルが存在する場合、Sync App は指定されたファイルからデフォルトレルムを取得します。それ以外の場合は、OS に基づいてデフォルトのMIT ロケーションからの読み取りを試みます：C:\ProgramData\MIT\Kerberos5\krb5.ini (Windows) または/etc/krb5.conf (Linux)
• ドメイン名およびホスト： Kerberos 領域およびKerberos KDC が別の場所から推測できなかった場合、Sync App はユーザー設定されているドメイン名およびホストからそれらを推測します。これは、一部のWindows 環境で機能します。

Kerberos ドメインコントローラーのサービスプリンシパル名（SPN）。

解説

Kerberos ドメインコントローラーのSPN が認証先のURL と異なる場合は、このプロパティを使用してSPN を設定します。

Kerberos プリンシパルと暗号化されたキーのペアを含むKeytab ファイル。

解説

Kerberos のプリンシパルと暗号化されたキーのペアを含むKeytab ファイル。

サービスのKerberos レルム。

解説

KerberosServiceRealm は、クロスレルムKerberos 認証を使用するときにサービスKerberos レルムを指定するために使われます。

ほとんどの場合、単一のレルムとKDC マシンがKerberos 認証を実行するために使用され、このプロパティは必要ありません。

このプロパティは、異なるレルムとKDC マシンを使用して認証チケット（AS リクエスト）およびサービスチケット（TGS リクエスト）を取得する、より複雑な設定で使用できます。

サービスのKerberos KDC。

解説

KerberosServiceKDC は、クロスレルムKerberos 認証を使用するときにサービスKerberos KDC を指定するために使われます。

ほとんどの場合、単一のレルムとKDC マシンがKerberos 認証を実行するために使用され、このプロパティは必要ありません。

このプロパティは、異なるレルムとKDC マシンを使用して認証チケット（AS リクエスト）およびサービスチケット（TGS リクエスト）を取得する、より複雑な設定で使用できます。

MIT Kerberos 資格情報キャッシュファイルへのフルパス。

解説

このプロパティは、MIT Kerberos チケットマネージャーまたはkinit コマンドを使用して作成された資格情報キャッシュファイルを使用する場合に設定できます。

このセクションでは、本プロバイダーの接続文字列で設定可能なSSL プロパティの全リストを提供します。

SSL クライアント認証（2-way SSL）のためのTLS/SSL クライアント証明書ストア。

解説

クライアント証明書のための証明書ストア名。

SSLClientCertType フィールドは、SSLClientCert により指定された証明書ストアの種類を指定します。ストアがパスワードで保護されている場合は、SSLClientCertPassword でパスワードを指定します。

SSLClientCert は、SSLClientCertSubject フィールドとともにクライアント証明書を指定するために使われます。SSLClientCert に値がある場合で、SSLClientCertSubject が設定されている場合は、証明書の検索が始まります。詳しくは、SSLClientCertSubject を参照してください。

証明書ストアの指定はプラットフォームに依存します。

Windows の共通のユーザとシステム証明書ストアの指定は以下のとおりです。

Javaでは、証明書ストアは通常、証明書および任意の秘密キーを含むファイルです。

証明書ストアの種類がPFXFile の場合は、このプロパティにファイル名を設定します。PFXBlob の場合は、このプロパティをPFX ファイルのバイナリコンテンツ（例えば、PKCS12証明書ストア）に設定する必要があります。

TLS/SSL クライアント証明書を格納するキーストアの種類。

解説

このプロパティには次の値の一つを設定できます。

TLS/SSL クライアント証明書のパスワード。

解説

証明書ストアでパスワードが必要である場合、このプロパティを使用してパスワードを指定し、証明書ストアにアクセスできます。

TLS/SSL クライアント証明書のサブジェクト。

解説

証明書のサブジェクトは、証明書をロードするときにストア内の証明書を検索するために使用されます。

完全に一致するものが見つからない場合、ストアはプロパティの値を含むサブジェクトを検索します。それでも一致するものが見つからない場合、プロパティは空白で設定され、証明書は選択されません。

"*" に設定すると、証明書ストアの1番目の証明書が選択されます。

証明書のサブジェクトは識別の名前フィールドおよび値のカンマ区切りのリストです。例えば、"CN=www.server.com, OU=test, C=US, [email protected]" です。共通のフィールドとその説明は以下のとおりです。

フィールド値にカンマが含まれている場合は、それを引用符で囲む必要があります。

TLS/SSL を使用して接続するときに、サーバーが受け入れ可能な証明書。

解説

TLS/SSL 接続を使用する場合は、このプロパティを使用して、サーバーが受け入れるTLS/SSL 証明書を指定できます。コンピュータによって信頼されていない他の証明書はすべて拒否されます。

このプロパティは、次のフォームを取ります：

これを指定しない場合は、マシンが信用するすべての証明書が受け入れられます。

すべての証明書の受け入れを示すには、'*'を使用します。セキュリティ上の理由から、これはお勧めできません。

このセクションでは、本プロバイダーの接続文字列で設定可能なSSH プロパティの全リストを提供します。

サービスへのSSH トンネルを確立する際に使用される認証方法。

解説

• None：認証は行われません。現在のUser の値は無視され、接続は匿名でログインされます。
• Password：Sync App は、User とPassword の値を使用してユーザーを認証します。
• Public_Key：Sync App は、User とSSHClientCert の値を使用してユーザーを認証します。SSHClientCert には、この認証方法を成功させるために使用可能な秘密鍵が必要です。

SSHUser の認証に使用する証明書。

解説

公開鍵認証を使用するには、SSHClientCert に有効な秘密鍵が含まれている必要があります。 公開鍵はオプションで、含まれていない場合はSync App が秘密鍵から生成します。 Sync App は公開鍵をサーバーに送信し、ユーザーが公開鍵を認証した場合に接続が許可されます。

SSHClientCertType フィールドは、SSHClientCert により指定されたキーストアの種類を指定します。 ストアがパスワードで保護されている場合は、SSHClientCertPassword でパスワードを指定します。

一部の種類のキーストアは、複数のキーを含むことができるコンテナです。 デフォルトでは、Sync App はストアの最初のキーを選択しますが、SSHClientCertSubject を使用して特定のキーを指定することも可能です。

SSHClientCert キーのパスワード（ある場合）。

解説

このプロパティは、SSHAuthMode がPublicKey に設定され、SSHClientCert が秘密鍵に設定されているSFTP サーバーに認証する場合にのみ使用されます。

SSH クライアント証明書のサブジェクト。

解説

証明書のサブジェクトは、証明書をロードするときにストア内の証明書を検索するために使用されます。

完全に一致するものが見つからない場合、ストアはプロパティの値を含むサブジェクトを検索します。

それでも一致するものが見つからない場合、プロパティは空白で設定され、証明書は選択されません。

"*" に設定すると、証明書ストアの1番目の証明書が選択されます。

証明書のサブジェクトは識別の名前フィールドおよび値のカンマ区切りのリストです。 例えば、"CN=www.server.com, OU=test, C=US, [email protected]"。共通のフィールドとその説明は以下のとおりです。

フィールド値にカンマが含まれている場合は、それを引用符で囲む必要があります。

SSHClientCert 秘密鍵の種類。

解説

このプロパティには次の値の1つを設定できます。

SSH サーバー。

解説

SSH サーバー。

SSH ポート。

解説

SSH ポート。

SSH ユーザー。

解説

SSH ユーザー。

SSH パスワード。

解説

SSH パスワード。

SSH サーバーのフィンガープリント。

解説

SSH サーバーのフィンガープリント。

MongoDB 接続をSSH 経由でトンネリングするかどうか。 SSH を使用します。

解説

デフォルトでは、Sync App はMongoDB に直接接続しようとします。 このオプションを有効にすると、Sync App は代わりにSSHServer とのSSH 接続を確立し、その接続を経由してMongoDB への接続をトンネリングします。

このセクションでは、本プロバイダーの接続文字列で設定可能なFirewall プロパティの全リストを提供します。

プロキシベースのファイアウォールで使われるプロトコル。

解説

このプロパティは、Sync App がFirewallServer プロキシ経由でトンネルトラフィックを使うためのプロトコルを指定します。

プロキシベースのファイアウォールの名前もしくはIP アドレス。

解説

ファイアウォールトラバーサルを許容するために設定するIP アドレス、DNS 名、もしくはプロキシホスト名を指定するプロパティです。プロトコルはFirewallType で指定されます。このプロパティとFirewallServer を使って、SOCKS 経由での接続、もしくはトンネリングが可能です。

プロキシベースのファイアウォールのTCP ポート。

解説

ファイアウォールトラバーサルを許容するために設定するプロキシベースのファイアウォールのTCP ポート。名前もしくはIP アドレスを指定するには、FirewallServer を使います。FirewallType でプロトコルを指定します。

プロキシベースのファイアウォールに認証するために使うユーザー名。

解説

FirewallUser およびFirewallPassword プロパティは、FirewallType により指定された認証方式に則り、FirewallServer、およびFirewallPort で指定されたプロキシに対しての認証に使われます。

プロキシベースのファイアウォールへの認証に使われるパスワード。

解説

このプロパティは、FirewallType により指定された認証メソッドに則り、FirewallServer およびFirewallPort で指定されたプロキシに渡されます。

このセクションでは、本プロバイダーの接続文字列で設定可能なLogging プロパティの全リストを提供します。

ログファイルに含めるコアモジュール。

解説

指定された（';' で区切られた）モジュールのみがログファイルに含まれます。デフォルトではすべてのモジュールが含まれます。

概要はログ ページを参照してください。

このセクションでは、本プロバイダーの接続文字列で設定可能なSchema プロパティの全リストを提供します。

テーブル、ビュー、およびストアドプロシージャを定義するスキーマファイルを格納するディレクトリへのパス。

解説

Sync App のスキーマファイル（テーブルとビューの場合は.rsd ファイル、ストアドプロシージャの場合は.rsb ファイル）を含むディレクトリへのパス。このフォルダの場所は、実行ファイルの場所からの相対パスにすることができます。Location プロパティは、定義をカスタマイズしたり（例えば、カラム名を変更する、カラムを無視するなど）、新しいテーブル、ビュー、またはストアドプロシージャでデータモデルを拡張する場合にのみ必要です。

指定しない場合、デフォルトの場所は"%APPDATA%\\CData\\MongoDB Data Provider\\Schema" となり、%APPDATA% はユーザーのコンフィギュレーションディレクトリに設定されます：

このプロパティは、使用可能なスキーマのサブセットにレポートされるスキーマを制限します。例えば、BrowsableSchemas=SchemaA,SchemaB,SchemaC です。

解説

スキーマをデータベースからリストすると、負荷がかかる可能性があります。接続文字列でスキーマのリストを提供すると、 パフォーマンスが向上します。

このプロパティは、使用可能なテーブルのサブセットにレポートされるテーブルを制限します。例えば、Tables=TableA,TableB,TableC です。

解説

テーブルを複数のデータベースからリストすると、負荷がかかる可能性があります。接続文字列でテーブルのリストを提供すると、Sync App のパフォーマンスが向上します。

このプロパティは、作業したいビューがすでにわかっていて、ビューが多すぎる場合に、ビューを自動的にリストする代わりに使用することもできます。

カンマ区切りのリストで使用したいテーブルを指定します。各テーブルは、角かっこ、二重引用符、またはバッククオートを使用してエスケープされた特殊文字列を含む有効なSQL 識別子である必要があります。 例えば、Tables=TableA,[TableB/WithSlash],WithCatalog.WithSchema.`TableC With Space` です。

複数のスキーマまたはカタログを持つデータソースに接続する場合は、複数のカタログやスキーマに存在するテーブル間の曖昧さを避けるため、最後の例のように、このプロパティにテーブルの完全修飾名を指定する必要があることに注意してください。

使用可能なテーブルのサブセットにレポートされるビューを制限します。例えば、Views=ViewA,ViewB,ViewC です。

解説

ビューを複数のデータベースからリストすると、負荷がかかる可能性があります。接続文字列でビューのリストを提供すると、Sync App のパフォーマンスが向上します。

このプロパティは、作業したいビューがすでにわかっていて、ビューが多すぎる場合に、ビューを自動的にリストする代わりに使用することもできます。

カンマ区切りのリストで使用したいビューを指定します。各ビューは、角かっこ、二重引用符、またはバッククオートを使用してエスケープされた特殊文字列を含む有効なSQL 識別子である必要があります。 例えば、Views=ViewA,[ViewB/WithSlash],WithCatalog.WithSchema.`ViewC With Space` です。

複数のスキーマまたはカタログを持つデータソースに接続する場合は、複数のカタログやスキーマに存在するテーブル間の曖昧さを避けるため、最後の例のように、このプロパティにテーブルの完全修飾名を指定する必要があることに注意してください。

このセクションでは、本プロバイダーの接続文字列で設定可能なMiscellaneous プロパティの全リストを提供します。

A list of column name mappings for MongoDB's built-in columns.

解説

This property takes a comma-separated list of MongoDB column names for built-in columns and maps them to new names.

The remappable built-in columns are "_index" and "P_id".

For example:

_index=BuiltInIndex,P_id=Parent_Id

Remapping these columns is particularly useful for resolving "column names must be unique" errors that can arise when the Sync App finds additional columns named "_index" or "P_id" other than the built-in columns.

By default, the provider will not automatically discover the metadata for a child table as its own distinct table. To enable this functionality, set DataModel to Relational .

解説

When setting DataModel to Relational, the discovery of child tables extends to root level elements and those found within top-level array elements.

デフォルトで、ネスト配列はJSON 文字列として返されます。 FlattenArrays プロパティはネスト配列のエレメントをフラット化してそれぞれのカラムとするために使われます。ネスト配列から返すエレメントの数に FlattenArrays を設定します。

解説

デフォルトで、ネスト配列はJSON 文字列として返されます。FlattenArrays プロパティはネスト配列のエレメントをフラット化してそれぞれのカラムとするために使われます。これは短い配列の場合にのみ推奨されます。

ネスト配列から返すエレメントの数にFlattenArrays を設定します。特定されたエレメントはカラムとして返されます。Zero-base のインデックスはカラム名にコンカテネートされます。他のエレメントは無視されます。

例えば、文字列の配列からエレメントのアービトラリー数を返すことができます。

["FLOW-MATIC","LISP","COBOL"]

FlattenArrays を-1 に設定すると、ネストされた配列のすべてのエレメントをフラット化します。

フラット化されたオブジェクトプロパティとしてカラムを表示するには、 FlattenObjects をtrue に設定します。そうでなければ、配列にネストされたオブジェクトはJSON 文字列として返されます。

解説

フラット化されたオブジェクトプロパティとしてカラムを表示するには、FlattenObjects をtrue に設定します。そうでなければ、配列にネストされたオブジェクトはJSON 文字列として返されます。カラム名を生成するために、Sync App はプロパティ名をオブジェクト名にドットでコンカティネイトします。

例えば、次のネストされたオブジェクトを接続時にフラット化できます。

[
     { "grade": "A", "score": 2 },
     { "grade": "A", "score": 6 },
     { "grade": "A", "score": 10 },
     { "grade": "A", "score": 9 },
     { "grade": "B", "score": 14 }
]

スキーマを生成して保存するユーザーの好みのタイミングを示します。

解説

GenerateSchemaFiles を使用すると、自動スキーマ検出 によって識別されたテーブル定義を保存できます。 このプロパティは、Location で指定されたパスの.rsd ファイルにスキーマをアウトプットします。

有効な設定は次のとおりです。

• Never：スキーマファイルは生成されません。
• OnUse：スキーマファイルがまだ存在していない場合に、初めてテーブルが参照されるときにスキーマファイルが生成されます。
• OnStart：現在スキーマファイルを持たないあらゆるテーブルに対して、接続時にスキーマファイルが生成されます。
• OnCreate：CREATE TABLE SQL クエリを実行すると、スキーマファイルが生成されます。

SQL でスキーマを生成する

GenerateSchemaFiles をOnUse に設定すると、Sync App はSELECT クエリを実行したときにスキーマを生成します。スキーマはクエリのそれぞれの参照されたテーブルに対して生成されます。

GenerateSchemaFiles をOnCreate に設定すると、CREATE TABLE クエリが実行されたときにのみスキーマが生成されます。

接続時にスキーマを生成する

このプロパティのもう一つの使い方は、接続するときにデータベース内のすべてのテーブルのスキーマを取得することです。これには、GenerateSchemaFiles をOnStart に設定して接続します。

静的スキーマの別の方法

データ構造が変化する場合には、GenerateSchemaFiles をNever に設定して動的なスキーマを使うことを検討してください。動的なスキーマの詳細については、自動スキーマ検出 を参照してください。

スキーマの編集

スキーマファイルはシンプルな形式となっており、変更は簡単です。詳しくは、カスタムスキーマ定義 を参照してください。

クエリで集計またはGROUP BY を使用しない場合に返される行数を制限します。これはLIMIT 句よりも優先されます。

解説

クエリで集計またはGROUP BY を使用しない場合に返される行数を制限します。これはLIMIT 句よりも優先されます。

サーバーは通常、余分なメモリの使用を防ぐために、インアクティブ期間（10分間）後に、アイドル状態のカーソルをタイムアウトします。これを防ぐために、このオプションを設定します。

解説

サーバーは通常、余分なメモリの使用を防ぐために、インアクティブ期間（10分間）後に、アイドル状態のカーソルをタイムアウトします。これを防ぐために、このオプションを設定します。

これらの隠しプロパティは特定のユースケースでのみ使用されます。

解説

以下にリストされているプロパティは、特定のユースケースで使用可能です。通常のドライバーのユースケースおよび機能では、これらのプロパティは必要ありません。

複数のプロパティをセミコロン区切りリストで指定します。

統合およびフォーマット

MongoDB から返されるページあたりの結果の最大数。

解説

Pagesize プロパティは、MongoDB から返されるページあたりの結果の最大数に影響を与えます。より大きい値を設定すると、1ページあたりの消費メモリが増える代わりに、パフォーマンスが向上する場合があります。

このプロパティは、テーブルのカラムとして疑似カラムが含まれているかどうかを示します。

解説

Entity Framework ではテーブルカラムでない疑似カラムに値を設定できないため、この設定はEntity Framework で特に便利です。この接続設定の値は、"Table1=Column1, Table1=Column2, Table2=Column3" の形式です。"*=*" のように"*" 文字を使用して、すべてのテーブルとすべてのカラムを含めることができます。

このオプションは、クエリをMongoDB にas-is で渡します。

解説

True に設定すると、指定されたクエリがMongoDB にそのまま渡されます。現在サポートされているのは以下のshell コマンドのみです。

• db.myCollection.find() returns all fields for all records in the collection.
• db.myCollection.find({ query }) returns all fields for all records in the collection matching the query.
• db.myCollection.find({ query }, { projection }) returns the fields in the projection, for all records matching the query.
• All of the above forms accept a .json() suffix. This returns a single column containing the matching documents as JSON instead of individual fields.

レプリカセットから読み取るためのストラテジーに設定します。受容される値は、primary、primaryPreferred、secondary、secondaryPreferred、およびnearest です。

解説

このプロパティを使用すると、プライマリメンバー以外のレプリカセット内のメンバにクエリを実行できるようになります。受容される値は次のとおりです。

• primary：すべてのSELECT クエリが、プライマリサーバーに対して実行されます。
• primaryPreferred：プライマリサーバーが利用できない場合、SELECT クエリはセカンダリサーバーに対して実行されます。
• secondary：すべてのSELECT クエリは、セカンダリサーバーに対して実行されます。
• secondaryPreferred：セカンダリサーバーが利用可能な場合、セカンダリサーバーにSELECT クエリが実行されます。そうでない場合は、プライマリサーバーに対して実行されます。
• nearest：SELECT クエリは、レイテンシが最小のサーバーに対して実行されます。

ReadPreference を使用するタイミング

このプロパティを設定すると、書き込み操作がセカンダリマシンにまだレプリケートされていない場合、最新の変更がクエリ結果に反映されないことがあります。 ReadPreference を使用すると、Sync App が古いデータを返すリスクはありますが、次のことを達成できます。

• フェイルオーバークエリの設定：プライマリサーバーが利用できない場合、このプロパティを"primaryPreferred" に設定すると、オンラインでクエリを実行し続けることができます。
• 地理的に分散したレプリカセットに対してより高速にクエリを実行：デプロイメントで複数のデータセンターが使用されている場合、ReadPreference を"nearest" に設定すると、Sync App はレイテンシが最小のレプリカセットメンバーに対してSELECT クエリを実行するためクエリの処理速度が向上します。

Sync App にSELECT ステートメントをセカンダリサーバーに実行させる場合は、SlaveOK も設定する必要があります。そうしないと、Sync App はエラー応答を返します。

Use this property to target a replica set member or members that are associated with tags.

解説

To make use of ReadPreferenceTags you must configure ReadPreference to a value other than the primary value (the default value). The required format is a list of semicolon seperated tag sets where each tag set is a list of key value pairs separated by commas. For example:

• tag1:val1,tag2:val2;: Find members with both tag values. If none are found, find any eligible member.
• tag1:val1;tag2:val2;: Find members with the specified tag1, otherwise find members with the specified tag2. If none are found find any eligible member.
• tag1:val1: Find only members with the specified tag.
• ;: (semicolon only) Find any eligible member. If left empty, any eligible member is targeted.

The maximum number of rows to scan to look for the columns available in a table.

解説

The columns in a table must be determined by scanning table rows. This value determines the maximum number of rows that will be scanned.

Setting a high value may decrease performance. Setting a low value may prevent the data type from being determined properly, especially when there is null data.

Setting to a value of -1 causes the Sync App to scan an arbitrary number of rows until it reaches the final row.

このプロパティは、provider がセカンダリ（スレーブ）サーバーからの読み込みを認めるかどうかを設定します。

解説

このプロパティは、Sync App がレプリカセットのセカンダリ（スレーブ）サーバーからの読み込みを認めるかどうかを設定します。 Sync App がReadPreference でセカンダリサーバーをどのようにクエリするかを微調整できます。

タイムアウトエラーがスローされ、処理をキャンセルするまでの秒数。

解説

Timeout が0に設定されている場合は、操作がタイムアウトしません。処理が正常に完了するか、エラー状態になるまで実行されます。

Timeout の有効期限が切れても処理が完了していない場合は、Sync App は例外をスローします。

各ドキュメントコレクションのフィールドおよびデータタイプを決定するために、provider がデータをどのようにスキャンするかを示すカンマ区切りのオプション。

解説

Sets replacing or merging target document with updating fields is performed by executing update statement.

解説

Sets replacing or merging target document with updating fields is performed by executing update statement. When the default value Default is used, the Sync App updates the target document by replacing the whole original document with new one. When the value is set to Merge, only the specific field in the target document will be updated.

For example, if you have a collection 'classySample' as below.

{
  "_id": "1",
  "message": {
    "component_items": [{"locked": true}],
    "id":1
  }
}

UPDATE [classySample] SET [message.component_items.0.locked] = false  WHERE [message.id] = 1

In the query above, the 'message' document will be replaced with new document constructed with SET clause, the collection after updating looks like

{
  "_id": "1",
  "message": {
    "component_items": [
      {
        "locked": false
      }
    ]
  }
}

But when using Merge, only the 'locked' field in 'component_items' will be updated, the collection becomes

{
    "_id": "1",
    "message": {
        "component_items": [
            {
                "locked": false
            }
        ],
        "id": 1
    }
}

Execute MongoDB queries using db.collection.find().

解説

Amazon DocumentDB doesn't support the legacy OP_QUERY interface, so this must be set to True to query DocumentDB clusters with db.collection.find() instead.

カスタムビューを含むJSON コンフィギュレーションファイルを指すファイルパス。

解説

ユーザー定義ビューは、UserDefinedViews.json というJSON 形式のコンフィギュレーションファイルで定義されています。Sync App は、このファイルで指定されたビューを自動的に検出します。

また、複数のビュー定義を持ち、UserDefinedViews 接続プロパティを使用して制御することも可能です。このプロパティを使用すると、指定されたビューのみがSync App によって検知されます。

このユーザー定義ビューのコンフィギュレーションファイルは、次のようにフォーマットされています。

• 各ルートエレメントはビューの名前を定義します。
• 各ルートエレメントには、query と呼ばれる子エレメントが含まれており、この子エレメントにはビューのカスタムSQL クエリが含まれています。

次に例を示します。

{
	"MyView": {
		"query": "SELECT * FROM [CData].[Sample].Customers WHERE MyColumn = 'value'"
	},
	"MyView2": {
		"query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
	}
}

"UserDefinedViews", C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json

Requests acknowledgment that the write operation has propagated to the specified number of mongod instances.

解説

Requests acknowledgment that the write operation has propagated to the specified number of mongod instances.

Requires acknowledgment that the mongod instances, as specified in the WriteConcern property, have written to the on-disk journal.

解説

It requests acknowledgment that the mongod instances, as specified in the WriteConcern property, have written to the on-disk journal.

This option specifies a time limit, in milliseconds, for the write concern.

解説

This option specifies a time limit, in milliseconds, for the write concern.

Sets whether the object type for inserted or updated objects is determined from the existing column metadata or the input value type.

解説

Sets whether the object type for inserted or updated objects is determined from the existing column metadata or the input value type. When the default value Metadata is used, the Sync App uses the data type as determined by the TypeDetectionScheme for objects pushed to MongoDB. When the value is set to RawValue, the type of the object in the INSERT determines what type is used for MongoDB.

For example, if you have a field 'c1' in MongoDB defined as String type, the metadata returns the column as String as well. In the following query, the resulting field in MongoDB is therefore defined as String when using WriteScheme=Metadata. But when using RawValue, the inserting field type is Date instead since the FROM_UNIXTIME() function returns an actual Date object:

INSERT INTO Table1 (c1) VALUES (FROM_UNIXTIME(1636910867039, 0))

Inserting an empty array

INSERT INTO t1 ("c1") VALUES (())

This returns an empty array:

"c1":[]