Sync App アプリケーションの接続 ページに移動し、接続の追加 パネルで対応するアイコンを選択して、Elasticsearch への接続を作成します。Elasticsearch アイコンが利用できない場合は、Add More アイコンをクリックしてCData サイトからElasticsearch コネクタをダウンロードおよびインストールします。

必須プロパティは［設定］タブにリストされています。［Advanced］タブには、通常は必要ない接続プロパティが表示されます。

Elasticsearch サービスへの接続

データに接続するには以下を設定します。

• Server は、Elasticsearch インスタンスのIP アドレスもしくはドメインに設定する必要があります。また、Server にはシングルクラスタのノードアドレス、またはホスト名のカンマ区切りのリストを設定することもできます。
  

  Server=https://01.02.03.04 
    OR 
  Server=https://01.01.01.01:1234,https://02.02.02.02:5678

• Port は、Elasticsearch インスタンス用に構成されたポートに設定する必要があります。Server プロパティのノードの仕様にポートを含めると、そのノードに限り、その含めたポートがPort の仕様より優先されます。

Sync App は、認証とTLS/SSL 暗号化にX-Pack Security を使用しています。サーバーの値の前に"https://" を付けると、TLS/SSL で接続できます。

Amazon OpenSearch Service への接続

データに接続するには以下を設定します。

• Server はAmazon ES インスタンスのエンドポイントURL に設定する必要があります。
• Port は443に設定します。
• AWSRegion はElasticsearch インスタンスがホストされているAmazon AWS リージョンに設定する必要があります（Sync App はServer 値に基づいて自動的にリージョンを識別しようとします）。

Sync App は、認証とTLS/SSL 暗号化にX-Pack Security を使用しています。

Note： リクエストはAWS 署名バージョン 4 を使用して署名されています。

Elasticsearch への認証

AWS キーを取得

IAM ユーザーの認証情報を取得するには、以下の手順に従ってください。

1. IAM コンソールにサインインします。
2. ナビゲーションペインで［ユーザー］を選択します。
3. ユーザーのアクセスキーを作成または管理するには、ユーザーを選択してから［セキュリティ認証情報］タブを選択します。

AWS ルートアカウントの認証情報を取得するには、以下の手順に従ってください。

1. ルートアカウントの認証情報を使用してAWS 管理コンソールにサインインします。
2. アカウント名または番号を選択し、表示されたメニューで［My Security Credentials］を選択します。
3. ［Continue to Security Credentials］をクリックし、［Access Keys］セクションを展開して、ルートアカウントのアクセスキーを管理または作成します。

標準認証

AuthScheme をBasic に設定し、User とPassword プロパティを設定して、オプションでPKI（公開鍵暗号基盤）を使用して認証します。Sync App が接続されると、X-Pack では、設定したレルムをベースにユーザー認証およびロールの許可が実施されます。

PKI を使用するには、SSLClientCert、SSLClientCertType、SSLClientCertSubject、およびSSLClientCertPassword プロパティを設定します。

Note： PKI を使用するためには、TLS/SSL およびクライアント認証はX-Pack 上で有効化されていなければなりません。

セキュアなElasticsearch への接続

Sync App においてTLS/SSL を有効化するには、Server 値に'https://' 接頭辞を追加します。

ルートクレデンシャル

アカウントのルートクレデンシャルで認証するには、次を設定します。

• AuthScheme：AwsRootKeys に設定。
• AWSAccessKey：AWS ルートアカウントに紐づいているアクセスキー。
• AWSSecretKey：AWS ルートアカウントに紐づいているシークレットキー。

Note： この認証スキームの使用は、簡単なテスト以外ではAmazon では推奨されていません。アカウントのルート認証情報はユーザーの完全な権限を持つため、これが最も安全性の低い認証方法になります。

一時クレデンシャル

一時クレデンシャルで認証するには、次を設定します。

• AuthScheme：TemporaryCredentials に設定。
• AWSAccessKey：ロールを担うIAM ユーザーのアクセスキー。
• AWSSecretKey：ロールを担うIAM ユーザーのシークレットキー。
• AWSSessionToken：AWS のセッショントークン。これは一時的な認証情報とともに提供されます。詳しくは、AWS Identity and Access Management User Guide を参照してください。

Sync App は、一時クレデンシャルの有効期間中、長期的な認証情報（IAM ユーザー認証情報など）によって提供されるものと同じ権限を使用してリソースをリクエストできるようになりました。

認証にIAM ロールも使用している場合は、さらに以下を指定する必要があります。

• AWSRoleARN：認証したいロールのRole ARN を指定。これにより、Sync App は指定されたロールの認証情報を 取得しようと試みます。
• AWSExternalId（オプション）：別のアカウントでロールを引き受ける場合にのみ必要です。

AWS IAM ロール

多くの場合、認証にはAWS ルートユーザーのダイレクトなセキュリティ認証情報ではなく、IAM ロールを使用することをお勧めします。

AWS ロールとして認証するには、次を設定します。

• AuthScheme：AwsIAMRoles に設定。
• AWSAccessKey：ロールを担うIAM ユーザーのアクセスキー。
• AWSSecretKey：ロールを担うIAM ユーザーのシークレットキー。
• AWSRoleARN：認証したいロールのRole ARN を指定。これにより、Sync App は指定されたロールの認証情報を 取得しようと試みます。
• AWSExternalId（オプション）：別のアカウントでロールを引き受ける場合にのみ必要です。

Note： AWS ルートユーザーのAWSAccessKey およびAWSSecretKey を指定する場合、ロールは使用できません。

Kerberos

Kerberos で認証する方法についての詳細は、Kerberos の使用 を参照してください。

API キー

APIKey を使用して認証するには、次を設定します。

• AuthScheme：APIKey に設定。
• APIKey：Elasticsearch から返されたAPIKey に設定。
• APIKeyId：APIKey と一緒に返されたId に設定。

このセクションでは、Kerberos でElasticsearch に認証する方法を説明します。

Kerberos

Kerberos を使用してElasticsearch に認証するには、次のプロパティを設定します。

• AuthScheme：NEGOTIATE に設定。
• KerberosKDC：Kerberos KDC マシンのホスト名またはIP アドレスに設定。
• KerberosSPN：Elasticsearch のKerberos プリンシパルのサービスとホストに設定。これは、principal value（例：HTTP/[email protected]）の'@' 記号の前の値（例：HTTP/MyHost）です。

Kerberos チケットの取得

次のオプションのいずれかを使用して、必要なKerberos チケットを取得できます。

MIT Kerberos 資格情報キャッシュファイル

このオプションを使用すると、MIT Kerberos チケットマネージャーまたはkinit コマンドを使ってチケットを取得できます。このオプションでは、User またはPassword 接続プロパティを設定する必要はないことに注意してください。

1. KRB5CCNAME という名前の環境変数が作成されていることを確認してください。
2. KRB5CCNAME 環境変数をクレデンシャルキャッシュファイルを指すパスに設定します（例えばC:\krb_cache\krb5cc_0 または/tmp/krb5cc_0）。このファイルは、MIT Kerberos チケットマネージャーでチケットを生成するときに作成されます。
3. チケットを取得するには、MIT Kerberos チケットマネージャーアプリケーションを開き、Get Ticket をクリックしてプリンシパル名とパスワードを入力し、OK をクリックします。成功すると、チケット情報がKerberos チケットマネージャーに表示され、クレデンシャルキャッシュファイルに保存されます。
4. クレデンシャルキャッシュファイルを作成したので、Sync App はキャッシュファイルを使用してElasticsearch に接続するためのKerberos チケットを取得します。

KRB5CCNAME 環境変数を設定する代わりに、KerberosTicketCache プロパティを使用してファイルパスを直接設定できます。 設定すると、Sync App は指定されたキャッシュファイルを使用してElasticsearch に接続するためのKerberos チケットを取得します。

Keytab ファイル

KRB5CCNAME 環境変数が設定されていない場合、Keytab ファイルを使用してKerberos チケットを取得できます。これを行うには、User プロパティを目的のユーザー名に設定し、KerberosKeytabFile プロパティをユーザーに関連付けられたキータブファイルを指すファイルパスに設定します。

User およびPassword

KRB5CCNAME 環境変数およびKerberosKeytabFile プロパティの両方が設定されていない場合、ユーザーとパスワードの組み合わせを使用してチケットを取得できます。これを行うには、User およびPassword プロパティを、Elasticsearch での認証に使用するユーザー / パスワードの組み合わせに設定します。

クロスレルム

より複雑なKerberos 環境では、複数のレルムおよびKDC サーバーが使用されるクロスレルム認証が必要になる場合があります（例えば、1つのレルム / KDC がユーザー認証に使用され、別のレルム / KDC がサービスチケットの取得に使用される場合）。

このような環境では、KerberosRealm およびKerberosKDC プロパティをユーザー認証に必要な値に設定します。また、KerberosServiceRealm およびKerberosServiceKDC プロパティを、 サービスチケットの取得に必要な値に設定します。

データアクセスのファインチューニング

次のプロパティを使って、Elasticsearch API 機能およびSync App のストラテジーをさらに制御できます。

• QueryPassthrough：このプロパティを使用すると、SQL の代わりにElasticsearch のSearch DSL 言語を使用できます。
• RowScanDepth：このプロパティは、テーブルメタデータを生成する際にカラムのデータ型を検出するためにスキャンされる行数を指定します。このプロパティは、自動スキーマ検出 から生成された動的スキーマを使用している場合、またはQueryPassthrough を使用している場合に適用されます。

Querying Multiple Indices

Multiple indices can be queried by executing a query using one of the following formats:

• Query all indices via the _all view: SELECT * FROM [_all]

• Query a list of indices: SELECT * FROM [index1,index2,index3]

• Query indices matching a wildcard pattern: SELECT * FROM [index*]

Note, index lists can contain wildcards and indices can be excluded by prefixing an index with '-'. For example: SELECT * FROM [index*,-index3]

Fine Tuning Performance

• PageSize: This property enables you to optimize performance based on your resource provisioning.
  Paging has an impact on sorting performance in a distributed system, as each shard must first sort results before submitting them to the coordinating server.
  By default, the Sync App requests a page size of 10,000. This is the default index.max_result_window setting in Elasticsearch.
• MaxResults: This property sets a limit on the results for queries at connection time, without requiring that you specify a LIMIT clause.
  By default, this is the same value as the index.max_result_window setting in Elasticsearch.

  If you are using the Scroll API, set ScrollDuration instead.

• ScrollDuration: This property specifies how long the server should keep the search context alive. Setting this property to a nonzero value and time unit enables the Scroll API.

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

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

自動スキーマ検出 スキーマは、Elasticsearch タイプのマッピングを取得することにより自動的にデータ型を検出します。Elasticsearch コレクションのリレーショナル表現をコントロールするためにRowScanDepth、FlattenArrays、およびFlattenObjects を使うことができます。

CData Sync App はElasticsearch REST API を、標準SQL でアクセス可能なリレーショナルテーブルおよびストアドプロシージャとしてモデル化します。これにより、標準ベースのツールからのアクセスが可能になります。

テーブル定義は動的に取得されます。接続すると、Sync App はElasticsearch に接続し、スキーマ、テーブルのリストおよびテーブルのメタデータをElasticsearch REST サーバーをクエリすることで取得します。 リモートデータへのあらゆる変更はクエリに即時に反映されます。

次のテーブルはElasticsearch コンセプトをリレーショナルなものにマップします。

Elasticsearch バージョン6以上：

Note：Starting in Elasticsearch 6, indices are limited to a single type.Therefore the type is no longer treated as a table, since an index and type have a one-to-one relation. Types are hidden and used internally where necessary to issue the proper request to Elasticsearch.

Elasticsearch バージョン6より前：

Elasticsearch contains the ability to establish parent-child relationships. This relationship maps closely to SQL JOIN functionality. The Sync App models these parent-child relationships in a way to enable the ability to perform JOIN queries.

Elasticsearch Versions 6 and Above:

In version 6 and above of Elasticsearch, relationships are established by using the join datatype. Included in this functionality is the ability to define multiple children for a single parent and to create multiple levels of relations.

The Sync App supports all of these relationships and will generate a separate table for each relation in Elasticsearch. The table name will be in the form: [index]_[relation].

All child tables will have an additional column containing the parent table id. The column name will be in the form: _[parent_table]_id. This column is a foreign key to the _id column of the parent table and can be used to perform SQL JOIN queries.

When querying these tables individually, filtering logic is pushed to the server to improve performance by only returning the data relevant to the table selected.

Elasticsearch Versions Prior to Version 6:

In versions prior to 6, a relationship is established between two types via a _parent field. This creates a single parent-child relationship.

The tables identified in this parent-child relationship do not change (they are still based on the Elasticsearch type). However the child table will have an additional column containing the parent id. The column name will be in the form: _[parent_table]_id. This column is a foreign key to the _id column of the parent table and can be used to perform SQL JOIN queries.

この章で使用されている生データを示します。以下は、"insured" テーブル（インデックス）のマッピングです。

{
  "insured": {
    "mappings": {
      "properties": {
        "name": { "type":"string" },
        "address": {
          "street": { "type":"string" },
          "city": { "type":"string" },
          "state": { "type":"string" }
        },
        "insured_ages": { "type": "integer" },
        "vehicles": {
          "type": "nested",
          "properties": {
            "year": { "type":"integer" },
            "make": { "type":"string" },
            "model": { "type":"string" },
            "body_style" { "type": "string" }
          }
        }
      }
    }
  }
}

以下は、"insured" テーブル（インデックス）のサンプルデータセットです。

{
  "hits": {
    "total": 2,
    "max_score": 1,
    "hits": [
      {
        "_index": "insured",
        "_type": "_doc",
        "_id": "1",
        "_score": 1,
        "_source": {
          "name": "John Smith",
          "address": {
            "street": "Main Street",
            "city": "Chapel Hill",
            "state": "NC"
          },
          "insured_ages": [ 17, 43, 45 ],
          "vehicles": [
            {
              "year": 2015,
              "make": "Dodge",
              "model": "RAM 1500",
              "body_style": "TK"
            },
            {
              "year": 2015,
              "make": "Suzuki",
              "model": "V-Strom 650 XT",
              "body_style": "MC"
            },
            {
              "year": 1992,
              "make": "Harley Davidson",
              "model": "FXR",
              "body_style": "MC"
            }
          ]
        }
      },
      {
        "_index": "insured",
        "_type": "_doc",
        "_id": "2",
        "_score": 1,
        "_source": {
          "name": "Joseph Newman",
          "address": {
            "street": "Oak Street",
            "city": "Raleigh",
            "state": "NC"
          },
          "insured_ages": [ 23, 25 ],
          "vehicles": [
            {
              "year": 2010,
              "make": "Honda",
              "model": "Accord",
              "body_style": "SD"
            },
            {
              "year": 2008,
              "make": "Honda",
              "model": "Civic",
              "body_style": "CP"
            }
          ]
        }
      }
    ]
  }
}

Sync App は、Elasticsearch タイプのマッピングを取得することで、リレーショナルスキーマを自動的に推測します。カラムおよびデータ型は取得されたマッピングから生成されます。

配列の検出

Elasticsearch のあらゆるフィールドは、値の配列となることができますが、これはマッピング中では明示的に定義されてはいません。これに対応するため、Sync App はデータをクエリして、配列を含むフィールドがあるかどうかを調べます。 この配列スキャンのために取得するElasticsearch ドキュメントの数はRowScanDepth プロパティで設定されます。

Elasticsearch のネストされたタイプは、オブジェクトの配列を表す特別なタイプであり、そのためメタデータの生成ではそのように扱われます。

カラムの検出

検出プロセスで特定されるカラムはFlattenArrays およびFlattenObjects によります。

データセットの例

これらのオプションがどう動作するかの例として、次のマッピングを考えます（テーブル名は'insured' です）。

{
  "insured": {
    "properties": {
      "name": { "type":"string" },
      "address": {
        "street": { "type":"string" },
        "city": { "type":"string" },
        "state": { "type":"string" }
      },
      "insured_ages": { "type": "integer" },
      "vehicles": {
        "type": "nested",
        "properties": {
          "year": { "type":"integer" },
          "make": { "type":"string" },
          "model": { "type":"string" },
          "body_style" { "type": "string" }
        }
      }
    }
  }
}

また、上の例において、次のサンプルデータを考えてください：

{
  "_source": {
    "name": "John Smith",
    "address": {
      "street": "Main Street",
      "city": "Chapel Hill",
      "state": "NC"
    },
    "insured_ages": [ 17, 43, 45 ], 
    "vehicles": [
      {
        "year": 2015,
        "make": "Dodge",
        "model": "RAM 1500",
        "body_style": "TK"
      },
      {
        "year": 2015,
        "make": "Suzuki",
        "model": "V-Strom 650 XT",
        "body_style": "MC"
      },
      {
        "year": 2012,
        "make": "Honda",
        "model": "Accord",
        "body_style": "4D"
      }
    ]
  }
}

FlattenObjects の使用

FlattenObjects が設定されている場合、すべてのネストされたオブジェクトは連続したカラムにフラット化されます。上記の例は、次のカラムとして表示されます：

FlattenObjects が設定されていない場合、address.street、address.city、およびaddress.state カラムは別々にはなりません。文字列型の住所カラムは一つのオブジェクトとして表されます。 値は次のようになります：

{street: "Main Street", city: "Chapel Hill", state: "NC"}

FlattenArrays の使用

FlattenArrays プロパティは配列の値をフラット化してそれぞれのカラムとするために使われます。これは配列が短い場合にのみ推奨されます。アンバウンドの配列をそのままにしておき、必要な際にJSON 関数 を使ってデータを取り出すことをお勧めします。

Note：一番上の配列のみがフラット化されます。サブ配列は、配列全体として表示されます。

FlattenArrays プロパティは3に設定して上の例の配列を次のように表すことができます（この例ではFlattenObjects は設定されていません）：

FlattenObjects とFlettenArrays を両方使う

FlattenObjects とFlattenArrays が同時に設定されている（brevity は1）場合、vehicle フィールドは次のように表されます：

Sync App には、ドキュメントをテーブルとしてモデル化するための3つの基本的な設定があり、次のセクションで説明します。 Sync App はElasticsearch ドキュメントを解析してネストされたドキュメントを識別します。

• フラット化されたドキュメントモデル：ネストされたドキュメントを単一のテーブルに暗黙的に結合します。
• リレーショナルモデル：ネストされたドキュメントを、親ドキュメントにリンクする主キーと外部キーを含む個々のテーブルとしてモデル化します。
• トップレベルのドキュメントモデル：Elasticsearch ドキュメントのトップレベルのビューをモデル化します。ネストされたドキュメントはJSON 文字列として返されます。

ネストされたElasticsearch のデータ全体にアクセスする必要があるユーザーにとっては、データを単一テーブルにフラット化することは最善のオプションです。このモードでは、Sync App はストリーミングを使用し、クエリごとにElasticsearch のデータを1回だけパースします。

オブジェクト配列を単一テーブルに結合

DataModel を"FlattenedDocuments" に設定すると、ネストされたドキュメントは別々のテーブルとして振る舞い、SQL JOIN と同じ方法で動作します。同じ高さのネストされたドキュメント（例えば兄弟ドキュメント）は、SQL CROSS JOIN として扱われます。

例

以下は、Raw データ のサンプルドキュメントに基づいたサンプルクエリとその結果です。これにより、insured ドキュメントとネストされたvehicles ドキュメントが暗黙のうちにJOIN されます。

クエリ

次のクエリは、各insured ドキュメントのネストされたドキュメントをドリルします。

SELECT
  [_id],
  [name],
  [address.street] AS address_street,
  [address.city.first] AS address_city,
  [address.state.last] AS address_state,
  [insured_ages],
  [year],
  [make],
  [model],
  [body_style],
  [_insured_id],
  [_vehicles_c_id]
FROM
  [insured]

結果

関連項目

• 自動スキーマ検出：テーブルスキーマに報告されたカラムを設定します。
• FreeForm;：ドット表記を使用して、ネストされたデータを選択します。
• VerticalFlattening;：ネストされたオブジェクト配列に別々のテーブルとしてアクセスします。
• JSON 関数：クライアント側の集計と変換を実行するために返されたデータを操作します。

Elasticsearch データのトップレベルドキュメントビューを使用すると、トップレベルの要素にすぐにアクセスできます。Sync App は、集計にネストされた要素を単一のカラムとして返します。

考慮すべき一つの側面はパフォーマンスです。ネストされたエレメントを処理してパースする時間とリソースを控えます。Sync App は、JSON データを読み込むためにストリーミングを使用して、返されたデータを一度パースします。もう一つ考慮すべきは、ネストされた親エレメントに格納されているデータにアクセスする必要があることと、ツールやアプリケーションがJSON を処理する能力です。

トップレベルドキュメントビューのモデリング

DataModel が"Document"（デフォルト）に設定されている場合、Sync App はデフォルトでトップレベルのオブジェクトのみをスキャンします。デフォルトのオブジェクトフラット化により、トップレベルのオブジェクトエレメントはカラムとして利用可能です。ネストされたオブジェクトは、集計されたJSON として返されます。

例

以下は、Raw データ のサンプルドキュメントに基づいたサンプルクエリとその結果です。クエリの結果、単一の"insured" テーブルが作成されます。

クエリ

次のクエリは、トップレベルのオブジェクトエレメントと車両配列を結果にプルします。

SELECT
  [_id],
  [name],
  [address.street] AS address_street,
  [address.city] AS address_city,
  [address.state] AS address_state,
  [insured_ages],
  [vehicles]
FROM
  [insured]
  

結果

データのドキュメントビューでは、（FlattenObjects をtrue に設定するとき）address オブジェクトが3カラムにフラット化され、_id, name、insured_ages 、およびvehicles エレメントが個別のカラムとして返され、結果として7カラムのテーブルが作成されます。

[{"year":2015,"make":"Dodge","model":"RAM 1500","body_style":"TK"},{"year":2015,"make":"Suzuki","model":"V-Strom 650 XT","body_style":"MC"},{"year":1992,"make":"Harley Davidson","model":"FXR","body_style":"MC"}]

[{"year":2010,"make":"Honda","model":"Accord","body_style":"SD"},{"year":2008,"make":"Honda","model":"Civic","body_style":"CP"}]

関連項目

• 自動スキーマ検出：水平フラット化を使用してカラム検出を設定します。
• FreeForm;：ドット表記を使用して、ネストされたデータを選択します。
• VerticalFlattening;：ネストされたオブジェクト配列に別々のテーブルとしてアクセスします。
• JSON 関数：クライアント側の集計と変換を実行するために返されたデータを操作します。

CData Sync App は、ネストされたドキュメントを主キーと親文書にリンクする外部キーを含む個別のテーブルとして扱うことで、データのリレーショナルモデルを作成するように設定できます。これは、リレーショナルデータモデルを想定している既存のBI、帳票、およびETL ツールでElasticsearch のデータを処理する必要がある場合に特に役立ちます。

ネストされた配列をテーブルとして結合

DataModel を"Relational" に設定すると、どの結合もクエリによって制御されます。JOIN クエリを実行するときはいつでも、Elasticsearch のインデックスはクエリに含まれる各テーブル（ネストされたドキュメント）に対して一度クエリされます。

例

以下は、リレーショナルモデルを使用したRaw データ のサンプルドキュメントに対するサンプルクエリです。

クエリ

次のクエリは、insured およびvehicles テーブルを明示的に結合します。

SELECT 
  [insured].[_id], 
  [insured].[name], 
  [insured].[address.street] AS address_street, 
  [insured].[address.city.first] AS address_city, 
  [insured].[address.state.last] AS address_state, 
  [insured].[insured_ages], 
  [vehicles].[year], 
  [vehicles].[make], 
  [vehicles].[model], 
  [vehicles].[body_style],
  [vehicles].[_insured_id],
  [vehicles].[_c_id]
FROM 
  [insured]
JOIN 
  [vehicles] 
ON 
  [insured].[_id] = [vehicles].[_insured_id]

結果

サンプルクエリでは、各vehicle ドキュメントがその親insured オブジェクトに結合され、5行のテーブルを作成します。

関連項目

• 自動スキーマ検出：テーブルスキーマに報告されたカラムを設定します。
• FreeForm;：ドット表記を使用して、ネストされたデータを選択します。
• VerticalFlattening;：ネストされたオブジェクト配列に別々のテーブルとしてアクセスします。
• JSON 関数：クライアント側の集計と変換を実行するために返されたデータを操作します。

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 Employee;

 
{
  "_index": "megacorp",
  "_type": "employee",
  "_id": "2",
  "_score": 1,
  "_source": {
    "first_name": "Jane",
    "last_name": "Smith",
    "age": 32,
    "about": "I like to collect rock albums",
    "interests": [
      "music"
    ]
  }
} 

このセクションでは、SQL 構文がどのようにElasticsearch クエリに変換されているかを説明します。さまざまなクエリの結果がどうなるかを説明するサンプルも示されています。

コンテキストのクエリ/フィルタリングおよびスコアリング

テキストマッチングおよび検索

このポイントをデモするために、Elasticsearch のanalyzed フィールドには'Bike' という値を作成しています。 解析後、この値は（デフォルトアナライザーを使って）逆引きインデックスに'bike' として格納されます。 一方、non-analyzed フィールドは検索値を解析せず、'Bike' として格納されます。

検索を実行する際には、いくつかのElasticsearch クエリタイプは、アナライザーを通じて検索値を実行します（これにより、検索は大文字・小文字の区別がなくなります）。いくつかのクエリタイプは、アナライザーを経由しません（大文字・小文字を区別します）。 また、デフォルトアナライザーは、複数の単語を持つフィールドを個別の単語に分割します。これらのフィールドに検索を実行する場合、 Elasticsearch は同じ単語を持つレコードを別の順番で返すことがあります。例えば、'blue sky' という値に対して検索が実行された場合でも'sky blue' のレコードが返されます。

この大文字・小文字の区別や順序の問題の回避には、CData Sync App は、カラムをanalyzed 、もしくはnon-analyzed に分類し、指定された演算子（= のような）に基づく適切なElasticsearch クエリを発行して、値を検索します。

イコールおよび非イコール

analyzed カラム
analyzed カラムはアナライザーを通された後に格納されます。その結果として、指定された検索値は、検索前にElasticsearch サーバーのアナライザーを通されます。これにより検索は大文字・小文字の区別がなくなります（使われたアナライザーが大文字・小文字を処理する前提で）。

Non-Analyzed Columns
non-analyzed カラムはアナライザーを通されずに格納されます。これにより、non-analyzed カラムは大文字・小文字の区別があり、これらのカラムの検索値は大文字・小文字を区別しなければなりません。検索値が1つの単語である場合、Sync App は3つの標準的な形式である、大文字、小文字、すべて大文字、で指定されたオリジナルケーシングでフィルタをチェックします。 検索値が複数の単語を含む場合、検索値はas-is で送られ、大文字・小文字の区別があります。

IN and NOT IN

LIKE およびNOT LIKE

Aggregate Filtering

JSON objects and arrays of objects will be treated as raw strings and all filtering will be performed by the Sync App. Therefore an equals operation must match the entire JSON aggregate to return a result, unless a CONTAINS or LIKE operation is used.

If JSON objects are flattened into individual columns (via FlattenObjects and FlattenArrays), the column for the specific JSON field will be treated as individual columns. Thus the data type will be that as contained in the Elasticsearch mapping and all filters will be pushed to the server (where applicable).

JSON primitive array aggregates will also be treated as raw strings by default and filters will be performed by the Sync App. To filter data based on whether a primitive array contains a single value, the INARRAY function can be used (e.g. INARRAY(column) = 'value'). When performing a search on array fields, Elasticsearch looks at each value individually within an array. Thus when the INARRAY function is specified in a WHERE clause, the filter will be pushed to the server which performs a search within an array.

Primitive arrays may consist of different data types, such as strings or ints. Therefore the INARRAY function supports comparison operators applicable to the data type within the Elasticsearch mapping for the field. For example, INARRAY(int_array) > 5, will return all rows of data in which the int_array contains a value greater than 5. Supported comparison operators include the use of the LIKE operator for string arrays.

ビュースキーマは、Elasticsearch タイプおよびクエリに対しSync App が推測するリレーショナル構造を固定します。カスタムスキーマがどう動作するかの例として、次のマッピングを使用します（テーブル名は'insured' です）。

{
  "insured": {
    "properties": {
      "name": { "type":"string" },
      "address": {
        "street": { "type":"string" },
        "city": { "type":"string" },
        "state": { "type":"string" }
      },
      "insured_ages": { "type": "integer" },
      "vehicles": {
        "type": "nested",
        "properties": {
          "year": { "type":"integer" },
          "make": { "type":"string" },
          "model": { "type":"string" },
          "body_style" { "type": "string" }
        }
      }
    }
  }
}

また、上の例において、次のサンプルデータを考えてください：

{
  "_source": {
    "name": "John Smith",
    "address": {
      "street": "Main Street",
      "city": "Chapel Hill",
      "state": "NC"
    },
    "insured_ages": [ 17, 43, 45 ], 
    "vehicles": [
      {
        "year": 2015,
        "make": "Dodge",
        "model": "RAM 1500",
        "body_style": "TK"
      },
      {
        "year": 2015,
        "make": "Suzuki",
        "model": "V-Strom 650 XT",
        "body_style": "MC"
      },
      {
        "year": 2012,
        "make": "Honda",
        "model": "Accord",
        "body_style": "4D"
      }
    ]
  }
}

カスタムスキーマの定義

GenerateSchemaFiles が設定されている場合の固定されたスキーマは、Location プロパティによって指定されたフォルダに配置されます。例えば、GenerateSchemaFiles を"OnUse" に設定して、SELECT クエリを実行します：

SELECT * FROM insured

生成されたスキーマでカラムの動作を変更できます。次のスキーマは、other:xPathプロパティを使って、特定のカラムへのデータがどこに取得されるべきかを定義します。このモデルを使って、階層構造のアービトラリーレベルをフラット化することができます。

es_index およびes_type 属性は、取得するElasticsearch インデックスおよびタイプを指定します。es_index およびes_type 属性は、同じタイプ内で複数のスキーマを使うフレキシビリティを与えます。es_type が指定されていない場合、ファイル名がパースされるコレクションを決定します。

以下は、カラム動作マークアップの例です。完全なスキーマはカスタムスキーマ例 を参照してください。

  <rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">  
  
    <rsb:info title="StaticInsured" description="Elasticsearch に insure されたデータセットのCustom Schema。">  
      <!-- Column definitions -->
      <attr name="_id"                         xs:type="string"  other:xPath="_id"                                                         other:sourceField="_id"                 other:analyzed="true"  />
      <attr name="_score"                      xs:type="double"  other:xPath="_score"                                                      other:sourceField="_score"              other:analyzed="true"  />
      <attr name="name"                        xs:type="string"  other:xPath="_source/name"                                                other:sourceField="name"                other:analyzed="true"  />
      <attr name="address.street"              xs:type="string"  other:xPath="_source/address/street"                                      other:sourceField="address.street"      other:analyzed="true"  />
      <attr name="address.city"                xs:type="string"  other:xPath="_source/address/city"                                        other:sourceField="address.city"        other:analyzed="true"  />
      <attr name="address.state"               xs:type="string"  other:xPath="_source/address/state"                                       other:sourceField="address.state"       other:analyzed="true"  />
      <attr name="insured_ages"                xs:type="string"  other:xPath="_source/insured_ages"          other:valueFormat="aggregate" other:sourceField="insured_ages"        other:analyzed="false" />
      <attr name="insured_ages.0"              xs:type="integer" other:xPath="_source/insured_ages[0]"                                     other:sourceField="insured_ages"        other:analyzed="false" />
      <attr name="vehicles"                    xs:type="string"  other:xPath="_source/vehicles"              other:valueFormat="aggregate" other:sourceField="vehicles"            other:analyzed="true"  />
      <attr name="vehicles.0.year"             xs:type="integer" other:xPath="_source/vehicles[0]/year"                                    other:sourceField="vehicles.year"       other:analyzed="true"  />
      <attr name="vehicles.0.make"             xs:type="string"  other:xPath="_source/vehicles[0]/make"                                    other:sourceField="vehicles.make"       other:analyzed="true"  />
      <attr name="vehicles.0.model"            xs:type="string"  other:xPath="_source/vehicles[0]/model"                                   other:sourceField="vehicles.model"      other:analyzed="true"  />
      <attr name="vehicles.0.body_style"       xs:type="string"  other:xPath="_source/vehicles[0]/body_style"                              other:sourceField="vehicles.body_style" other:analyzed="true"  />
  
      <input name="rows@next" desc="データのページングに使われる内部属性。"  />
    </rsb:info>  
  
  
    <rsb:set attr="es_index" value="auto"/>
    <rsb:set attr="es_type"  value="insured"/>
  
  </rsb:script>
  

このセクションでは、コンプリートスキーマを説明します。インフォセクションではElasticsearch オブジェクトのリレーショナルビューを可能にします。詳細はカスタムスキーマ定義 を参照してください。 次のテーブルはSELECT コマンドのみをサポートしています。INSERT、UPDATE、およびDELETE コマンドは現在サポートされていません。

es_index およびes_type 属性を使って、Elasticsearch タイプの名前と、取得およびパースしたいインデックスを指定します。es_index およびes_index 属性を使って、同じElasticsearch タイプに対して複数のスキーマを定義することができます。

es_type が指定されていない場合、ファイル名がパースされるElasticsearch タイプを決定します。

スキーマにrows@next input をas-is でコピーします。 elasticsearchadoSelect のような操作は内部実装で、そのままコピーができます。

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

  <rsb:info title="StaticInsured" description="Elasticsearch にinsure されたデータセットのCustom Schema。">  
    <!-- Column definitions -->
    <attr name="_id"                         xs:type="string"  other:xPath="_id"                                                         other:sourceField="_id"                 other:analyzed="true"  />
    <attr name="_score"                      xs:type="double"  other:xPath="_score"                                                      other:sourceField="_score"              other:analyzed="true"  />
    <attr name="name"                        xs:type="string"  other:xPath="_source/name"                                                other:sourceField="name"                other:analyzed="true"  />
    <attr name="address.street"              xs:type="string"  other:xPath="_source/address/street"                                      other:sourceField="address.street"      other:analyzed="true"  />
    <attr name="address.city"                xs:type="string"  other:xPath="_source/address/city"                                        other:sourceField="address.city"        other:analyzed="true"  />
    <attr name="address.state"               xs:type="string"  other:xPath="_source/address/state"                                       other:sourceField="address.state"       other:analyzed="true"  />
    <attr name="insured_ages"                xs:type="string"  other:xPath="_source/insured_ages"          other:valueFormat="aggregate" other:sourceField="insured_ages"        other:analyzed="false" />
    <attr name="insured_ages.0"              xs:type="integer" other:xPath="_source/insured_ages[0]"                                     other:sourceField="insured_ages"        other:analyzed="false" />
    <attr name="vehicles"                    xs:type="string"  other:xPath="_source/vehicles"              other:valueFormat="aggregate" other:sourceField="vehicles"            other:analyzed="true"  />
    <attr name="vehicles.0.year"             xs:type="integer" other:xPath="_source/vehicles[0]/year"                                    other:sourceField="vehicles.year"       other:analyzed="true"  />
    <attr name="vehicles.0.make"             xs:type="string"  other:xPath="_source/vehicles[0]/make"                                    other:sourceField="vehicles.make"       other:analyzed="true"  />
    <attr name="vehicles.0.model"            xs:type="string"  other:xPath="_source/vehicles[0]/model"                                   other:sourceField="vehicles.model"      other:analyzed="true"  />
    <attr name="vehicles.0.body_style"       xs:type="string"  other:xPath="_source/vehicles[0]/body_style"                              other:sourceField="vehicles.body_style" other:analyzed="true"  />

    <input name="rows@next" desc="データのページングに使われる内部属性。"  />
  </rsb:info>  

  <rsb:set attr="es_index" value="auto"/>
  <rsb:set attr="es_type"  value="insured"/>

  <rsb:script method="GET">
    <rsb:call op="elasticsearchadoSelect">
      <rsb:push/>
    </rsb:call>
  </rsb:script>

  <rsb:script method="POST">
    <rsb:call op="elasticsearchadoModify">
      <rsb:push/>
    </rsb:call>
  </rsb:script>

  <rsb:script method="MERGE">
    <rsb:call op="elasticsearchadoModify">
      <rsb:push/>
    </rsb:call>
  </rsb:script>

  <rsb:script method="DELETE">
    <rsb:call op="elasticsearchadoModify">
      <rsb:push/>
    </rsb:call>
  </rsb:script>

</rsb:script>

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

ユーザー定義ビュー

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

SSL の設定

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

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

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

クエリ処理

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

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

ログ

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

SSL 設定のカスタマイズ

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

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

クライアントSSL 証明書

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

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

Firewall またはProxy 経由の接続

HTTP プロキシ

Windows のシステムプロキシ経由の接続では、接続プロパティを追加で設定する必要はありません。他のプロキシに接続するには、ProxyAutoDetect をfalse に設定します。

さらにHTTP プロキシへの認証には、ProxyServer とProxyPort に加えてProxyAuthScheme、ProxyUser、およびProxyPassword を設定します。

その他のプロキシ

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

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

CData Sync App は、Elasticsearch エンティティをリレーショナルテーブル、ビュー、およびストアドプロシージャにモデル化します。

テーブル

SQL での検索 では、テーブルが動的に取得される方法を詳細に説明します。

ビュー

Views are treated in a similar manner to Tables and thus exhibit similar behavior. There are some differences in the background though which are a direct result of how aliases work within Elasticsearch. (Note: In the following description, 'alias', 'index', 'type', and 'field' are referring to the Elasticsearch objects and not directly to anything within the Sync App).

Views (aliases) are tied to an index and thus span all the types within an index. Additionally aliases can span multiple indices. Therefore you may see an alias (view) listed multiple times under different schemas (index). When querying the view, regardless of the schema specified, data will be retrieved and returned for all indices and types associated with the corresponding alias. Thus the generated metadata will contain a column for each field within each type of each index associated with the alias.

SQL での検索 では、ビューが動的に取得される方法を詳細に説明します。

The ModifyIndexAliases stored procedure can be used to create index aliases within Elasticsearch.

In addition to the Elasticsearch aliases, an '_all' view is returned which enables querying the _all endpoint to retrieve data for all indices in a single query.

ストアドプロシージャ

データ型のマッピング

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

*個々のタイプを持つ複数のフィールドにパースされます（FlattenArrays 参照）

Authentication

Connection

AWS Authentication

Kerberos

SSL

Firewall

Proxy

Logging

Schema

Miscellaneous

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

認証で使用されるスキーム。None、Basic、Negotiate (Kerberos)、AwsRootKeys、AwsIAMRoles、およびAPIKey のエントリーが許容されます。デフォルト値はNone です。

解説

このフィールドは、サーバーに対して認証をするために使われます。次のオプションを使って、認証スキームを選択してください。

• None：BASIC 認証が実行されるUser およびPassword プロパティが設定されていない限り、認証は実行されません。
• Basic：Basic 認証が行われます。
• Negotiate：AuthScheme がNegotiate に設定された場合、Sync App は認証メカニズムをサーバーとネゴシエートします。Kerberos 認証を使いたい場合はAuthScheme をNegotiate に設定します。
• AwsRootKeys：ルートユーザーのアクセスキーおよびシークレットが使用されます。クイックテストには便利ですが、本番環境のユースケースでは、権限を絞ったものを使用することをお勧めします。
• AwsIAMRoles：接続にIAM ロールが使用されます。
• APIKey：接続にAPIKey とAPIKeyId を使用するように設定します。

Elasticsearch に認証を行っているユーザー。

解説

Elasticsearch に認証を行っているユーザー。

Elasticsearch への認証に使われるパスワード。

解説

Elasticsearch への認証に使われるパスワード。

Elasticsearch REST サーバーのホスト名またはIP アドレス。Alternatively, multiple nodes in a single cluster can be specified, though all such nodes must be able to support REST API calls.

解説

Elasticsearch REST サーバーのホスト名またはIP アドレス。Alternatively, multiple nodes in a single cluster can be specified, though all such nodes must be able to support REST API calls.

SSL を使用するには、ホスト名またはIP アドレスの前に'https://' を付け、SSLServerCert のSSL 接続プロパティを設定します。

To specify multiple nodes, set the property to a comma delimited list of addresses, with ports optionally specified after the address and delimited from the address by a colon. For example, you could specify two dedicated, coordinating nodes for your cluster with 'https://01.01.01.01:1234,https://02.02.02.02:5678'. If a port is specified with a node, that port will take precedence over the Port property for connections to that node only.

Elasticsearch REST サーバーのポート。

解説

Elasticsearch REST サーバーが割り振られているポート。

The APIKey used to authenticate to Elasticsearch.

解説

The APIKey used to authenticate to Elasticsearch.

The APIKey Id to authenticate to Elasticsearch.

解説

The APIKey Id to authenticate to Elasticsearch.

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

Elasticsearch ドキュメントをパースしてデータベースのメタデータを生成するときに使用するデータモデルを指定します。

解説

DataModel 設定を選択して、Sync App がネストされたドキュメントをテーブルにモデル化する方法を設定します。 さまざまな設定でデータをクエリする例については、階層データの解析 を参照してください。

データモデリングストラテジーの選択

次のDataModel 設定が利用可能です。さまざまな設定でデータをクエリする例については、階層データの解析 を参照してください。

• Document

  各ドキュメントの行を表す単一テーブルを返します。このデータモデルでは、ネストされたドキュメントはフラット化されず、集計として返されます。

• FlattenedDocuments

  親ドキュメントとネストされたドキュメントのJOIN を表す単一テーブルを返します。このデータモデルでは、ネストされたドキュメントはSQL JOIN と同じ作法で動作します。さらに、ネストされた兄弟ドキュメント（同じ高さのネストされたドキュメント）は、SQL CROSS JOIN として扱われます。Sync App は、返されたドキュメントを解析することによって、利用可能なネストされたドキュメントを識別します。

• Relational

  ドキュメント内のネストされたドキュメント（親ドキュメントを含む）に対して1つずつ、複数のテーブルを返します。このデータモデルでは、ネストされたドキュメントは、親テーブルにリンクする主キーと外部キーを含むリレーショナルテーブルとして返されます。

関連項目

• FlattenArrays およびFlattenObjects：これらのデータモデルごとに識別されるカラムをカスタマイズします。これらのプロパティの使用例については、自動スキーマ検出 を参照してください。
• 階層データの解析：異なるDataModel 設定から得られたスキーマを、サンプルクエリで比較します。
• SQL での検索：Sync App で利用可能なデータモデリングとフラット化のテクニックをについて学びます。

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

AWS アカウントのアクセスキー。この値には、［AWS セキュリティ認証情報］ページからアクセスできます。

解説

AWS アカウントのアクセスキー。この値には、［AWS セキュリティ認証情報］ページからアクセスできます。

1. ルートアカウントの認証情報を使用してAWS 管理コンソールにサインインします。
2. アカウント名または番号を選択し、表示されたメニューで［My Security Credentials］を選択します。
3. ［Continue to Security Credentials］をクリックし、［Access Keys］セクションを展開して、ルートアカウントのアクセスキーを管理または作成します。

AWS アカウントのシークレットキー。この値には、［AWS セキュリティ認証情報］ページからアクセスできます。

解説

AWS アカウントのシークレットキー。この値には、［AWS セキュリティ認証情報］ページからアクセスできます。

1. ルートアカウントの認証情報を使用してAWS 管理コンソールにサインインします。
2. アカウント名または番号を選択し、表示されたメニューで［My Security Credentials］を選択します。
3. ［Continue to Security Credentials］をクリックし、［Access Keys］セクションを展開して、ルートアカウントのアクセスキーを管理または作成します。

認証時に使用するロールのAmazon リソースネーム。

解説

AWS の外部で認証する場合は、AWS アカウント認証情報ではなく、ロールを認証に使用するのが 一般的です。AWSRoleARN を入力すると、CData Sync App はAWSAccessKey とAWSSecretKey を直接 使用する代わりに、ロールベースの認証を実行します。この認証を実行するためには、AWSAccessKey と AWSSecretKey を指定する必要があります。RoleARN を設定するときは、AWS ルートユーザーの 認証情報を使用できません。AWSAccessKey およびAWSSecretKey はIAM ユーザーのものである必要があります。

Amazon Web サービスのホスティングリージョン。

解説

Amazon Web サービスのホスティングリージョン。利用可能な値はOHIO、NORTHERNVIRGINIA、NORTHERNCALIFORNIA、OREGON、CAPETOWN、HONGKONG、JAKARTA、MUMBAI、OSAKA、SEOUL、SINGAPORE、SYDNEY、TOKYO、CENTRAL、BEIJING、NINGXIA、FRANKFURT、IRELAND、LONDON、MILAN、PARIS、STOCKHOLM、ZURICH、BAHRAIN、UAE、SAOPAULO、GOVCLOUDEAST、GOVCLOUDWEST です。

AWS のセッショントークン。

解説

AWS のセッショントークン。この値はさまざまな方法で取得できます。詳しくは、this link を参照してください。

The amount of time (in seconds) an AWS temporary token will last.

解説

Temporary tokens are used with Role based authentication. Temporary tokens will eventually time out, at which time a new temporary token must be obtained. The CData Sync App will internally request a new temporary token once the temporary token has expired.

For Role based authentication, the minimum duration is 900 seconds (15 minutes) while the maximum if 3600 (1 hour).

A unique identifier that might be required when you assume a role in another account.

解説

A unique identifier that might be required when you assume a role in another account.

このセクションでは、本プロバイダーの接続文字列で設定可能な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 証明書を指定できます。コンピュータによって信頼されていない他の証明書はすべて拒否されます。

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

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

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

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

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

解説

このプロパティは、Sync App がFirewallServer プロキシ経由でトンネルトラフィックを使うためのプロトコルを指定します。デフォルトでは、Sync App はシステムプロキシに接続します。この動作を無効化し次のプロキシタイプのどれかで接続するには、ProxyAutoDetect をfalse に設定します。

HTTP プロキシへの接続には、ProxyServer およびProxyPort ポートを使ってください。HTTP プロキシへの認証には、ProxyAuthScheme、ProxyUser、およびProxyPassword を使ってください。

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

解説

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

Sync App はデフォルトでシステムプロキシを使うので注意してください。他のプロキシを使う場合には、ProxyAutoDetect をfalse に設定してください。

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

解説

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

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

解説

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

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

解説

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

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

これは、システムプロキシ設定を使用するかどうかを示します。これは他のプロキシ設定よりも優先されるため、カスタムプロキシ設定を使用するにはProxyAutoDetect をFALSE に設定する必要があります。

解説

これは他のプロキシ設定よりも優先されるため、カスタムプロキシ設定を使用するにはProxyAutoDetect をFALSE に設定する必要があります。

HTTP プロキシへの接続には、ProxyServer を参照してください。SOCKS やトンネリングなどの他のプロキシには、FirewallType を参照してください。

HTTP トラフィックをルートするためのプロキシのホストネームもしくはIP アドレス。

解説

HTTP トラフィックをルートするためのプロキシのホストネームもしくはIP アドレス。HTTP プロキシへの認証には、Sync App はHTTP、Windows(NTLM)、もしくはKerberos 認証タイプを使用することができます。

SOCKS プロキシを経由して接続する、もしくは接続をトンネルするには、FirewallType を参照してください。

デフォルトで、Sync App はsystem プロキシを使います。他のプロキシを使う場合には、ProxyAutoDetect をfalse に設定します。

ProxyServer プロキシが起動しているTCP ポート。

解説

HTTP トラフィックをリダイレクトするHTTP プロキシが実行されているポート。ProxyServer でHTTP プロキシを指定します。その他のプロキシタイプについては、FirewallType を参照してください。

ProxyServer プロキシへの認証で使われる認証タイプ。

解説

この値は、ProxyServer およびProxyPort で指定されるHTTP プロキシに認証するために使われる認証タイプを指定します。

Sync App は、デフォルトでsystem proxy settings を使い、追加での設定が不要です。他のプロキシへの接続をする場合には、ProxyServer およびProxyPort に加え、ProxyAutoDetect をfalse に設定します。認証するには、ProxyAuthScheme を設定し、必要な場合にはProxyUser およびProxyPassword を設定します。

認証タイプは、次のどれかになります。

• BASIC： Sync App はHTTP BASIC 認証を行います。
• DIGEST： Sync App はHTTP DIGEST 認証を行います。
• NEGOTIATE： Sync App は認証において有効なプロトコルに応じて、NTLM もしくはKereros トークンを取得します。
• PROPRIETARY： Sync App はNTLM もしくはKerberos トークンを発行しません。このトークンを、HTTP リクエストのAuthorization ヘッダーに含める必要があります。

SOCKS 5 認証のような他の認証タイプを使用するには、FirewallType を参照してください。

ProxyServer プロキシへの認証に使われるユーザー名。

解説

ProxyUser および ProxyPassword オプションは、ProxyServer で指定されたHTTP プロキシに対して接続および認証するために使用されます。

ProxyAuthScheme で使用可能な認証タイプを選択することができます。HTTP 認証を使う場合、これをHTTP プロキシで識別可能なユーザーのユーザー名に設定します。Windows もしくはKerberos 認証を使用する場合、このプロパティを次の形式のどれかでユーザー名に設定します。

user@domain
domain\user

ProxyServer プロキシへの認証に使われるパスワード。

解説

このプロパティは、NTLM(Windows)、Kerberos、もしくはHTTP 認証をサポートするHTTP プロキシサーバーに認証するために使われます。HTTP プロキシを指定するためには、ProxyServer およびProxyPort を設定します。認証タイプを指定するためにはProxyAuthScheme を設定します。

HTTP 認証を使う場合、さらにHTTP プロキシにProxyUser およびProxyPassword を設定します。

NTLM 認証を使う場合、Windows パスワードにProxyUser およびProxyPassword を設定します。Kerberos 認証には、これらを入力する必要があります。

SOCKS 5 認証もしくは、トンネリングは、FirewallType を参照してください。

デフォルトで、Sync App はsystem プロキシを使います。他のプロキシに接続する場合には、これをfalse に設定します。

ProxyServer プロキシへの接続時に使用するSSL タイプ。

解説

このプロパティは、ProxyServer で指定されたHTTP プロキシへの接続にSSL を使用するかどうかを決定します。この値は、AUTO、ALWAYS、NEVER、TUNNEL のいずれかです。有効な値は次のとおりです。

ProxyServer 経由での接続が免除される宛先ホスト名またはIP のセミコロン区切りのリスト。

解説

ProxyServer は、このプロパティで定義されたアドレスを除くすべてのアドレスに使用されます。セミコロンを使用してエントリを区切ります。

Sync App は、追加設定なしにデフォルトでシステムのプロキシ設定を使います。この接続のプロキシ例外を明示的に構成するには、ProxyAutoDetect をfalse に設定して、ProxyServer およびProxyPort を設定する必要があります。認証するには、ProxyAuthScheme を設定し、必要な場合にはProxyUser およびProxyPassword を設定します。

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

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

解説

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

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

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

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

解説

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

指定しない場合、デフォルトの場所は"%APPDATA%\\CData\\Elasticsearch 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` です。

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

フラット化されたオブジェクトとしてカラムを表示するか、オブジェクトプロパティをJSON 文字列として返すか。

解説

デフォルトで、配列にネストされたオブジェクトはJSON 文字列として返されます。FlattenObjects がtrue に設定されている場合、オブジェクトプロパティはそれぞれのカラムにフラット化されます。 プロパティ名は、カラム名を作り出すためにピリオド付きのオブジェクト名にコンカテネートされます。

例えば、次のネストされたオブジェクトをコネクションタイムでフラット化できます：

"manager": {
  "name": "Alice White",
  "age": 30
}

テーブルカラムとして返したいネストされた配列エレメントの数に FlattenArrays を設定します。デフォルトで、ネスト配列はJSON 文字列として返されます。

解説

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

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

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

"employees": [
  {
    "name": "John Smith",
    "age": 34
  },
  {
    "name": "Peter Brown",
    "age": 26
  },
  {
    "name": "Paul Jacobs",
    "age": 30
  }
]

バインドされていない配列にJSON パスを使う場合は、JSON 関数 を参照してください。

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

Set ClientSideEvaluation to true to perform Evaluation client side on nested objects.

解説

Set ClientSideEvaluation to true to perform Evaluation (GROUP BY, filtering) client side on nested objects.

For example, with ClientSideEvaluation set to false(default value), GROUP BY on nested object 'property.0.name' would be grouped as 'property.*.name', while if set to true, results would be grouped as 'property.0.name'.

Similarly, with ClientSideEvaluation set to false(default value), filtering on nested object 'property.0.name' would be filtered as 'property.*.name', while if set to true, results would be filtered as 'property.0.name'.

This would affect performance as query is evaluated client side.

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

解説

このプロパティは、Location で指定されたパスの.rsd ファイルにスキーマをアウトプットします。

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

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

SQL でスキーマを生成する

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

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

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

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

デフォルトのSearch API 使用時にElasticsearch から返される結果の最大数。

解説

このプロパティはElasticsearch に対応します。 index.max_result_window index setting.デフォルト値は、Elasticsearch のデフォルトリミットである10000 です。

この値は、Scroll API 使用時には適用されません。本API を使用するためにScrollDuration を設定。

クエリでLIMIT が指定されている場合、LIMIT はMaxResults よりも小さい場合に有効です。そうでない場合、返される結果数はMaxResults 値に制限されます。

結果ウィンドウが大きすぎるというエラーを受け取った場合には、Elasticsearch の設定よりも大きいMaxResults 値によるものです。 index.max_result_window index setting. MaxResults 値をindex.max_result_window index setting に合わせて変更するか、ScrollDuration を設定してScroll API を使用します。

クエリで集計またはグループ化を使用しない場合に返される行数を制限します。これにより、設計時にパフォーマンスの問題を回避できます。

解説

クエリで集計またはグループ化を使用しない場合に返される行数を制限します。これにより、設計時にパフォーマンスの問題を回避できます。

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

解説

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

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

統合およびフォーマット

Elasticsearch から返されるリクエストあたりの結果数。

解説

PageSize は、クエリに対してElasticsearch からのリクエストあたりの受け取られる結果の数をコントロールできます。

デフォルト値は10000 です。これはElasticsearch のデフォルト制限をベースにしています（Elasticsearch の index.max_result_window index setting）。

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

解説

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

このオプションを使用すると、正確なクエリをElasticsearch に渡すことができます。

解説

このプロパティをTrue に設定することで、Sync App がElasticsearch クエリを as-is でElasticsearch に渡すことができます。There are two options for submitting as-is queries to Elasticsearch:SQL and Search DSL.

SQL API

Elasticsearch version 6.3 and above supports a SQL API endpoint. When set to true, this option allows you to pass SQL queries directly to the Elasticsearch SQL API. Columns will be identified based on the metadata returned in the response.

Supported SQL syntax and commands can be found in the Elasticsearch documentation.

Note：SQL functionality is limited to what is supported by Elasticsearch.

Search DSL

Alternatively, queries can be submitted using Elasticsearch's Search DSL language, which includes Query DSL. This functionality is available in all versions of Elasticsearch.

サポートされるクエリ構文は次で説明されるクエリパススルー構文を使ったJSON です。

JSON パススルークエリ構文では、以下のエレメントがサポートされます：

index、type、docid、およびapiendpointはrequestdata が送信されるURL を生成するために使われます。 URL は次の形式を使って生成されます： [Server]:[Port]/[index]/[type]/[docid]/[apiendpoint]。JSON パススルーエレメントのどれかが指定されていない場合は、URL には追加されません。

以下に、パススルークエリの例を示します。この例では、megacorp.employee でlast_name に'smith' を含むものから初めの10のドキュメントを取得します。結果はfirst_name の降順で並べられます。

{ 
  "index": "megacorp", 
  "type": "employee", 
  "requestdata": 
  {
    "from": 0,
    "size": 10,
    "query": {"bool":{"must":{"term":{"last_name":"smith"}}}},
    "sort": {"first_name":{"order":"desc"}}
  }
}

QueryPassthrough を使う場合、metadata はレスポンスで返されたデータによって決まります。RowScanDepth はmetadata （カラムおよびタイプ）を判断するためにスキャンされるレコードの量を規定します。 Metadata がレスポンスデータに依存するため、パススルークエリは、SQL 構文を使って実行された類似のクエリとは異なる結果を表示することがあります。

テーブルメタデータの生成時にスキャンする最大の行数。このプロパティを使って、provider がどのように配列を検出するかをより深くコントロールすることができます。

解説

このプロパティはテーブルメタデータの生成時にデータ内の配列を特定する場合に使われます。Elasticsearch はどんなフィールドも配列とすることができ、マッピングデータにおいてどのフィールドが配列であるかを特定しません。 これにより、RowScanDepth 列がクエリ、およびスキャンされ、配列を含むフィールドの有無を判断します。

QueryPassthrough がtrue に設定されている場合、テーブル内のカラムはリクエストで返されたデータをスキャンすることで判断されなければなりません。 この値はテーブルメタデータを判断するためにスキャンされる行数の最大値を設定します。デフォルト値は 100です。

設定値が高い場合にはパフォーマンスが低下します。小さい値を設定すると、特にnull データがある場合には、データ型を正しく判定できない場合があります。

Scroll API 経由で結果を取得する際に使用するtime unit の指定。

解説

ゼロではない値が指定された場合、Scroll API が使用されます。

指定されたtime unit はElasticsearch に送られたそれぞれのリクエストにおいて送られ、サーバーがlive なコンテンツをどれぐらいの時間検索し続けるかを指定します。指定される値は、前のバッチの結果を実行するのに十分な時間であれば大丈夫で、すべてのデータを処理する時間をとる必要はありません。 これは、ScrollDuration 値がそれぞれのリクエストにおいて送られ、コンテキストtime を更新するからです。

すべての結果が取得されると、検索コンテキストはクリアされます。

この値の形式は[integer][time unit] です。次に例を示します。1m = 1 minute.

プロパティを'0' に設定することで、デフォルトのSearch API が使われます。このような場合、返される結果の最大数はMaxResults と同じになります。

Supported Time Units:

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

解説

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

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

Set this to true to set the generated table name as the complete source path when flattening nested documents using Relational DataModel .

解説

Set this to true to set the generated table name as the complete source path when flattening nested documents using Relational DataModel.

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

解説

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

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

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

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

次に例を示します。

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

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