コンテンツ コネクタは、企業のリポジトリ内のデータを走査して所定のデータソースを完成する目的で使われるソフトウェア プログラムです。Google は以下のコンテンツ コネクタ開発オプションを提供しています。
コンテンツ コネクタ SDK。これは、Python や JavaScript などの 説明します。Content Connector SDK は、コネクタをすばやく作成するための REST API を簡単に使えるようにしたラッパーです。この SDK でコンテンツ コネクタを作成する場合は、Content Connector SDK を使用してコンテンツ コネクタを作成するを参照してください。
低レベル REST API、その他の各種の API ライブラリ。Java を使用していない場合や、お客様のコードベースが REST API やライブラリに問題なく対応できる場合は、これらのオプションをご利用ください。この REST API を使用してコンテンツ コネクタを作成する場合は、REST API を使用してコンテンツ コネクタを作成するを参照してください。
コンテンツ コネクタで行われる標準的なタスクは次のとおりです。
- 構成パラメータを読み取り、処理する。
- インデックス登録可能な離散的なデータチャンク(これを「アイテム」と呼びます)をサードパーティのコンテンツ リポジトリから pull する。
- ACL、メタデータ、コンテンツ データを結合して、インデックス登録可能なアイテムを作成する。
- アイテムを Cloud Search データソースにインデックス登録する。
- (省略可)サードパーティのコンテンツ リポジトリからの変更通知を待ち受ける。変更通知をインデックス登録リクエストに変換し、これで Cloud Search データソースとサードパーティのリポジトリとの同期を維持する。なお、コンテンツ コネクタによるこのタスクは、リポジトリが変更検出機能に対応している場合にのみ行われます。
Content Connector SDK を使用してコンテンツ コネクタを作成する
以降のセクションでは、Content Connector SDK を使用してコンテンツ コネクタを作成する方法について説明します。
依存関係を設定する
SDK を使用するには、ビルドファイルに特定の依存関係を含める必要があります。使用するビルド環境の依存関係を表示するには、以下のタブをクリックします。
Maven
<dependency>
<groupId>com.google.enterprise.cloudsearch</groupId>
<artifactId>google-cloudsearch-indexing-connector-sdk</artifactId>
<version>v1-0.0.3</version>
</dependency>
Gradle
compile group: 'com.google.enterprise.cloudsearch',
name: 'google-cloudsearch-indexing-connector-sdk',
version: 'v1-0.0.3'
コネクタ構成を作成する
コネクタごとに対応する構成ファイルが存在し、コネクタはそこに含まれているパラメータ(お客様のリポジトリの ID など)を使用します。パラメータは次のように定義されます。
Key-Value ペア:
api.sourceId=1234567890abcdef
。
Google Cloud Search SDK には、すべてのコネクタで使用される Google 提供構成パラメータが複数含まれています。以下の Google 提供パラメータをお客様の構成ファイル内で宣言してください。
- コンテンツ コネクタの場合は、
api.sourceId
とapi.serviceAccountPrivateKeyFile
(これらのパラメータはロケーションを識別するため) 秘密鍵の情報が含まれています。
- ID コネクタの場合は、次のように
api.identitySourceId
を宣言する必要があります。 パラメータは、外部の ID ソースの場所を指定します。もし ユーザーを同期するには、api.customerId
を 企業用の Google Workspace アカウントを作成します。
他の Google 提供のデフォルト値をオーバーライドする場合以外は、 それらのパラメータを構成ファイルで宣言する必要はありません。 Google 提供の構成パラメータについて詳しくは、 詳細については、このモジュールの Google 提供の構成パラメータ。
独自のリポジトリ パラメータを定義して、お客様の構成ファイル内で使用することもできます。
構成ファイルをコネクタに渡す
システム プロパティ config
を設定して、構成ファイルを
あります起動時に -D
引数を使用してプロパティを設定できます。
表示されます。たとえば、次のコマンドはコネクタを起動します。
MyConfig.properties
構成ファイルに置き換えます。
java -classpath myconnector.jar;... -Dconfig=MyConfig.properties MyConnector
この引数がない場合、SDK はデフォルト構成にアクセスしようとします。
connector-config.properties
という名前のファイル。
使用する走査戦略を決める
コンテンツ コネクタの主な機能は、リポジトリを走査してそのデータをインデックス登録することです。お客様のリポジトリ内のデータの規模と配置に基づいて走査戦略を実装してください。お客様独自の戦略を設計することも、SDK に実装されている以下の戦略から選択することもできます。
- フル走査戦略
リポジトリ全体をスキャンして、すべてのアイテムを無分別にインデックス登録する戦略です。フル走査は、リポジトリの規模が小さく、インデックス登録するたびに全体を走査してもオーバーヘッドを許容できる場合によく使われる戦略です。
フル走査戦略は、概ね静的で階層構造を持たないデータを含む小規模なリポジトリに向いています。変更検出が困難なリポジトリや変更検出機能をサポートしていないリポジトリで使用することもあります。
- リスト走査戦略
すべての子ノードを含むリポジトリ全体をスキャンして各アイテムのステータスを確認した後、2 回目のパスで前回のインデックス登録以降に作成または更新されたアイテムのみをインデックス登録する戦略です。リスト走査戦略は、インデックスを更新するたびに全体を走査しなくてもよい場合に、既存のインデックスを増分更新するためによく使われる戦略です。
リスト走査戦略は、変更検出が困難なリポジトリや変更検出機能をサポートしていないリポジトリで、データが階層化されておらず、扱うデータセットが非常に大規模であるようなケースに向いています。
- グラフ走査
親ノード全体をスキャンして各アイテムのステータスを確認した後、その後、コネクタは 2 回目のパスを受け取り、インデックス処理のみを ルートノードにあるアイテムは、新しいアイテムであるか、前回のインデックス登録以降に更新されています。 最後に、コネクタはすべての子 ID を渡して、子ノードのアイテムをインデックスに登録します。 更新することもできます。コネクタは、該当するアイテムがすべて処理されるまで、すべての子ノードを再帰的にスキャンします。この種の走査は、通常、ID をすべてリストすることが現実的でない階層的なリポジトリに対して使われます。
この戦略は、一連のディレクトリやウェブページなど、クロールする必要がある階層データがある場合に適しています。
で確認できます。
これらの走査戦略は、それぞれテンプレート コネクタによって実装されます。 クラスをご覧ください。独自の走査戦略を実装することもできますが、 コネクタの開発を大幅にスピードアップできます。テンプレートを利用してコネクタを作成する場合は、使用する走査戦略に対応するセクションに進んでください。
テンプレート クラスを使用してフル走査コネクタを作成する
Google ドキュメントの当該セクションのコード スニペットは、FullTraversalSample サンプルからの抜粋です。
コネクタのエントリ ポイントを実装する
コネクタのエントリ ポイントは、
main()
メソッドを使用します。このメソッドの主なタスクは、
Application
そのクラスの情報を
start()
メソッドを使用してコネクタを実行します。
電話をかける前に
application.start()
使用
IndexingApplication.Builder
クラスをインスタンス化して
FullTraversalConnector
使用します。「
FullTraversalConnector
受け入れられるものは
Repository
そのオブジェクトのメソッドを実装します。次のコード スニペットは、
main()
メソッドを実装します。
SDK はバックグラウンドで
initConfig()
メソッド(コネクタの main()
メソッド呼び出し後の)
Application.build
。
「
initConfig()
メソッド
次のタスクを実行します。
- このメソッドを呼び出して、
Configuation.isInitialized()
メソッドをConfiguration
初期化されていないことを確認します。 - Google 提供の Key-Value で
Configuration
オブジェクトを初期化します。 あります。各 Key-Value ペアはConfigValue
Configuration
オブジェクト内のオブジェクト。
Repository
インターフェースを実装する
Repository
オブジェクトの唯一の目的は、走査と
リポジトリ アイテムのインデックス登録など)。使用する場合
Repository
内の特定のメソッドをオーバーライドするだけで済みます。
コンテンツ コネクタを作成します。オーバーライドするメソッドは、使用するテンプレートと走査戦略によって異なります。対象:
FullTraversalConnector
次のメソッドをオーバーライドします。
「
init()
メソッドを呼び出します。データ リポジトリの設定と初期化を行うには、init()
メソッドを使用します。「
getAllDocs()
メソッドを呼び出します。データ リポジトリ内のすべてのアイテムを走査してインデックス登録するには、getAllDocs()
メソッドを使用します。このメソッドは、(お客様の構成で定義した)スケジュール済みの走査ごとに 1 回呼び出されます。(省略可)
getChanges()
メソッドを呼び出します。リポジトリが変更検出をサポートしている場合は、getChanges()
メソッドを使用します。このメソッドは、(お客様の構成で定義した)スケジュール済みの増分走査ごとに 1 回呼び出され、変更されたアイテムを取得してインデックス登録します。(省略可)
close()
メソッドを呼び出します。リポジトリのクリーンアップを行う必要がある場合は、close()
をオーバーライドします。 メソッドを呼び出します。このメソッドは、コネクタのシャットダウン時に 1 回呼び出されます。
これらの各メソッドは、
Repository
オブジェクトは、なんらかのタイプの
ApiOperation
渡されます。ApiOperation
オブジェクトは、単一の、または
複数(IndexingService.indexItem()
など)
呼び出しを行い、リポジトリの実際のインデックス登録を行います。
カスタム構成パラメータを取得する
コネクタの構成を扱う際に、コネクタの
カスタムパラメータの
Configuration
渡されます。このタスクは通常、
Repository
クラスの
init()
メソッドを使用します。
Configuration
クラスには、さまざまなデータ型を取得するためのメソッドがいくつかあります。
構成から分離できます。各メソッドは ConfigValue
オブジェクトを返します。次に、
ConfigValue
オブジェクトの
get()
メソッドを使用して実際の値を取得できます。
次のスニペットは、
FullTraversalSample
データセットを取得する方法を
Configuration
オブジェクトから 1 つのカスタム整数値を取得する:
複数の値を含むパラメータを取得して解析するには、
Configuration
クラスの型パーサー: データを個別のチャンクに解析します。
チュートリアル コネクタからの次のスニペットでは、
getMultiValue
メソッドを使用して、GitHub リポジトリ名のリストを取得します。
フル走査を実行する
オーバーライド
getAllDocs()
フル走査を実行してリポジトリをインデックスに登録しますgetAllDocs()
メソッドはチェックポイントを受け入れます。チェックポイントは、プロセスが中断された場合に特定のアイテムからインデックス登録を再開する目的で使用します。お客様の
getAllDocs()
メソッドで次の操作を行います。
- アクセス許可を設定する。
- インデックス登録するアイテムのメタデータを設定する。
- メタデータとアイテムを結合して、インデックス登録可能な 1 つにする
RepositoryDoc
。 - インデックス登録可能な各アイテムを
getAllDocs()
から返されるイテレータにパッケージ化する メソッドを呼び出します。なお、getAllDocs()
は実際にはCheckpointCloseableIterable
反復処理であり、ApiOperation
各オブジェクトは、特定のインスタンスで実行される API リクエストRepositoryDoc
(インデックス登録など)。
一連のアイテムが大きすぎて 1 回の呼び出しで処理できない場合は、
チェックポイントを設定して
hasMore(true)
インデックス登録できるアイテムがまだあることを示します。
アイテムへのアクセス許可を設定する
リポジトリは、アイテムにアクセスできるユーザーまたはグループを識別するためにアクセス制御リスト(ACL)を使用します。ACL は、アイテムにアクセスできるグループまたはユーザーの ID のリストです。
リポジトリで使用する ACL を複製して、指定したユーザーのみが使用されるようにする必要があります。 アイテムにアクセスできるユーザーは、検索結果でそのアイテムを表示できます。「 アイテムをインデックス登録する際は、アイテムの ACL を含める必要があります。これにより、Google Cloud Search が適切なレベルでアクセスするために必要な情報が得られます クリックします。
Content Connector SDK は、リポジトリの ACL をモデル化するために必要な一連の ACL クラスやメソッドを潤沢に提供しているため、ほとんどのリポジトリに対応できます。アイテムをインデックス登録するときは、リポジトリ内の各アイテムの ACL を分析して、Google Cloud Search の対応する ACL を作成する必要があります。リポジトリの ACL で ACL の継承といったコンセプトが用いられている場合、その ACL をモデル化するのは厄介な作業になるかもしれません。Google Cloud Search の ACL の詳細は、Google Cloud Search の ACL を参照してください。
注: Cloud Search の Indexing API がサポートしているのは単一ドメインの ACL であって、クロスドメインの ACL ではありません。こちらの
Acl.Builder
クラスを使用して、ACL を使用して各アイテムへのアクセス権を設定します。次のコード スニペットは、
フル走査のサンプルから
すべてのユーザーまたは「プリンシパル」
(getCustomerPrincipal()
)
すべてのアイテムの「リーダー」に
(.setReaders()
)
表示されます。
ACL について理解し、リポジトリに合わせて ACL を適切にモデル化する必要があります。たとえば、あるファイル システムのファイルをインデックス登録するとき、そのファイル システムである種の継承モデルが用いられているために、子フォルダが親フォルダからアクセス権を継承する場合があります。ACL の継承をモデル化するためには、Google Cloud Search の ACL で解説している追加情報が必要です。
アイテムのメタデータを設定する
メタデータは Item
オブジェクトに格納されます。Item
を作成するには、以下が必要です。
一意の文字列 ID、アイテムタイプ、ACL、URL、アイテムの最低限の値です。
次のコード スニペットは、Item
を
IndexingItemBuilder
ヘルパークラスです。
インデックス登録可能なアイテムを作成する
アイテムのメタデータを設定したら、インデックス登録可能な実際の
[
RepositoryDoc.Builder
クラスです。次の例は、単一のインデックス登録可能なアイテムを作成する方法を示しています。
RepositoryDoc
は ApiOperation
の一種で、実際のデータ
IndexingService.indexItem()
リクエスト。
また、
setRequestMode()
メソッド(
RepositoryDoc.Builder
クラスを ASYNCHRONOUS
または SYNCHRONOUS
に設定してインデックス登録リクエストを指定します。
ASYNCHRONOUS
- 非同期モードでは、インデックス登録から表示までのレイテンシが長くなり、 は、インデックス登録リクエストに対する大量のスループットの割り当てに対応します。非同期モードは リポジトリ全体の初回インデックス登録(バックフィル)におすすめの方法です。
SYNCHRONOUS
- 同期モードを使用すると、インデックス登録からサービングまでのレイテンシが短縮され、
限られたスループットの割り当てに対応します。同期モードは、リポジトリの更新や変更をインデックス登録するケースで使うことをおすすめします。条件
指定しない場合、リクエスト モードはデフォルトで
SYNCHRONOUS
になります。
イテレータ内のインデックス登録可能な各アイテムをパッケージ化する
getAllDocs()
メソッドは Iterator
を返します。具体的には、
CheckpointCloseableIterable
、
/
RepositoryDoc
説明します。こちらの
CheckpointClosableIterableImpl.Builder
イテレータを作成して返すことができます。次のコード スニペットは、イテレータを構築して返す方法を示しています。
SDK は、イテレータの範囲に含まれる各インデックス登録呼び出しを実行します。
次のステップ
必要に応じて次の手順を行います。
- (省略可)インデックス登録のスループットが遅いと思われる場合は、
FullTraversalConnector
のインデックス登録率を上げるをご覧ください。 - (省略可)
close()
を実装する メソッドを使用して、シャットダウン前にすべてのリソースを解放できます。 - (省略可)Content Connector SDK で ID コネクタを作成する。
テンプレート クラスを使用してリスト走査コネクタを作成する
Cloud Search インデックス登録キューの目的は、リポジトリ内の各アイテムの ID(および必要に応じてハッシュ値)を保持することです。リスト走査コネクタは、Google Cloud Search インデックス登録キューにアイテム ID を push し、インデックス登録のためにそこから 1 つずつ取得します。Google Cloud Search はキューを維持管理し、キューの内容を比較することでアイテムのステータス(アイテムがリポジトリから削除済みかどうかなど)を確認します。Cloud Search リソースについて詳しくは、 インデックス登録キューの詳細については、このモジュールの Cloud Search インデックス登録キュー。
ドキュメントの当該セクションのコード スニペットは、ListTraversalSample サンプルからの抜粋です。
コネクタのエントリ ポイントを実装する
コネクタのエントリ ポイントは、
main()
メソッドを使用します。このメソッドの主なタスクは、
Application
そのクラスの情報を
start()
メソッドを使用してコネクタを実行します。
電話をかける前に
application.start()
使用
IndexingApplication.Builder
クラスをインスタンス化して
ListingConnector
使用します。ListingConnector
は、
Repository
そのオブジェクトのメソッドを実装します。次のスニペットは、
ListingConnector
とそれに関連する Repository
をインスタンス化します。
SDK はバックグラウンドで
initConfig()
メソッド(コネクタの main()
メソッド呼び出し後の)
Application.build
。
initConfig()
メソッド:
- このメソッドを呼び出して、
Configuation.isInitialized()
メソッドをConfiguration
初期化されていないことを確認します。 - Google 提供の Key-Value で
Configuration
オブジェクトを初期化します。 あります。各 Key-Value ペアはConfigValue
Configuration
オブジェクト内のオブジェクト。
Repository
インターフェースを実装する
Repository
オブジェクトの唯一の目的は、走査と
リポジトリ アイテムのインデックス登録など)。テンプレートを使用する場合は、テンプレートの
Repository
インターフェース内の特定のメソッドを呼び出して、コンテンツ コネクタを作成します。
オーバーライドするメソッドは、使用するテンプレートと走査戦略によって異なります。対象:
ListingConnector
次のメソッドをオーバーライドします。
「
init()
メソッドを呼び出します。データ リポジトリの設定と初期化を行うには、init()
メソッドを使用します。getIds()
メソッドを呼び出します。リポジトリ内のすべてのレコードの ID とハッシュ値を取得するには:getIds()
メソッドをオーバーライドする。getDoc()
メソッドを呼び出します。インデックスのアイテムを新たに追加、更新、変更、削除するには、getDoc()
メソッドを使用します。(省略可)
getChanges()
メソッドを呼び出します。リポジトリが変更検出をサポートしている場合は、getChanges()
メソッドを使用します。このメソッドは、(お客様の構成で定義した)スケジュール済みの増分走査ごとに 1 回呼び出され、変更されたアイテムを取得してインデックス登録します。(省略可)
close()
メソッドを呼び出します。リポジトリのクリーンアップを行う必要がある場合は、close()
をオーバーライドします。 メソッドを呼び出します。このメソッドは、コネクタのシャットダウン時に 1 回呼び出されます。
Repository
オブジェクトの各メソッドは、なんらかの種類のレスポンスを返します。
ApiOperation
渡されます。ApiOperation
オブジェクトは、単一の、または
複数(IndexingService.indexItem()
など)
呼び出しを行い、リポジトリの実際のインデックス登録を行います。
カスタム構成パラメータを取得する
コネクタの構成を扱う際に、コネクタの
カスタムパラメータの
Configuration
渡されます。このタスクは通常、
Repository
クラスの
init()
メソッドを使用します。
Configuration
クラスには、さまざまなデータ型を取得するためのメソッドがいくつかあります。
構成から分離できます。各メソッドは ConfigValue
オブジェクトを返します。次に、
ConfigValue
オブジェクトの
get()
メソッドを使用して実際の値を取得できます。
次のスニペットは、
FullTraversalSample
データセットを取得する方法を
Configuration
オブジェクトから 1 つのカスタム整数値を取得する:
複数の値を含むパラメータを取得して解析するには、
Configuration
クラスの型パーサー: データを個別のチャンクに解析します。
チュートリアル コネクタからの次のスニペットでは、
getMultiValue
メソッドを使用して、GitHub リポジトリ名のリストを取得します。
リスト走査を実行する
オーバーライド
getIds()
メソッドを使用して、リポジトリ内のすべてのレコードの ID とハッシュ値を取得できます。
getIds()
メソッドはチェックポイントを受け取ります。チェックポイントは、プロセスが中断された場合に特定のアイテムからインデックス登録を再開する目的で使用します。
次に、kubectl の
getDoc()
メソッドを使用して、Cloud Search インデックス登録キュー内の各アイテムを処理します。
アイテムの ID とハッシュ値を push する
オーバーライド
getIds()
を使用してアイテム ID とその関連コンテンツのハッシュ値を
できます。その後、ID とハッシュ値のペアをパッケージ化して、Cloud Search インデックス登録キューに対する push 操作リクエストを作成します。通常、ルート(または親)の ID が最初に push され、続いて子の ID が push されます。こうしてアイテムの階層全体が処理されます。
getIds()
メソッドは、チェックポイントを受け取る(最後のアイテムを表す)
表示されます。チェックポイントは、プロセスが中断された場合に特定のアイテムからインデックス登録を再開する目的で使用します。リポジトリ内のアイテムごとに、以下の操作を行います。
getIds()
メソッドのステップ:
- 各アイテムの ID と関連ハッシュ値をリポジトリから取得する。
- 各 ID とハッシュ値のペアを
PushItems
にパッケージ化します。 - 各
PushItems
を結合して、getIds()
メソッドを呼び出します。なお、getIds()
は実際にはCheckpointCloseableIterable
反復処理であり、ApiOperation
各オブジェクトは、特定のインスタンスで実行される API リクエストRepositoryDoc
などのタスクをキューに push できます。
次のコード スニペットは、各アイテムの ID とハッシュ値を取得する方法を示しています。
プロンプトに
PushItems
。
PushItems
は、アイテムを Cloud Search に push するための ApiOperation
リクエストです。
インデックス登録キュー。
次のコード スニペットは、
PushItems.Builder
クラスを使用して ID とハッシュ値を 1 つの push にパッケージ化し、
ApiOperation
。
アイテムは、Cloud Search インデックス登録キューに push 後、さらに処理されます。
各アイテムを取得して処理する
オーバーライド
getDoc()
: Cloud Search インデックス登録キュー内の各アイテムを処理します。
アイテムは、新しいアイテム、変更されるアイテム、変更されていないアイテム、ソースに存在しなくなったアイテムのいずれかです。
できます。新規または変更済みの各アイテムを取得してインデックス登録します。ソース リポジトリにもう存在しないアイテムをインデックスから取り除きます。
getDoc()
メソッドは、Google Cloud Search からアイテムを受け取ります。
インデックス登録キュー。キュー内のアイテムごとに、次の手順を実行します。
getDoc()
メソッド:
Cloud Search インデックス登録キュー内のアイテムの ID がリポジトリに存在するかどうかを確認し、存在しなければアイテムをインデックスから削除する。
インデックス登録対象のアイテムのステータスをポーリングし、アイテムが未変更(
ACCEPTED
)の場合は何もしない。変更済みまたは新規のアイテムをインデックス登録する:
- アクセス許可を設定する。
- インデックス登録するアイテムのメタデータを設定する。
- メタデータとアイテムを結合して、インデックス登録可能な 1 つにする
RepositoryDoc
。 RepositoryDoc
を返します。
注: ListingConnector
テンプレートは、null
getDoc()
メソッドを使用します。null
を返すと、NullPointerException.
になります。
削除対象のアイテムを処理する
次のコード スニペットは、アイテムがリポジトリに存在するかどうか確認して存在しない場合に削除する方法を示しています。
documents
は、リポジトリを表すデータ構造です。条件
documents
に documentID
がありません。次を返します。
APIOperations.deleteItem(resourceName)
インデックスからアイテムを削除します。
未変更のアイテムを処理する
次のコード スニペットは、Cloud Search インデックス登録キュー内のアイテムのステータスをポーリングし、未変更のアイテムを処理する方法を示しています。
未変更アイテムであるか確認するには、変更の可能性を示すアイテムのステータスとその他のメタデータを調べます。この例では、アイテムが変更されたかどうかを確認するために、メタデータであるハッシュを使用しています。
アイテムへのアクセス許可を設定する
リポジトリは、アイテムにアクセスできるユーザーまたはグループを識別するためにアクセス制御リスト(ACL)を使用します。ACL は、アイテムにアクセスできるグループまたはユーザーの ID のリストです。
リポジトリで使用する ACL を複製して、指定したユーザーのみが使用されるようにする必要があります。 アイテムにアクセスできるユーザーは、検索結果でそのアイテムを表示できます。「 アイテムをインデックス登録する際は、アイテムの ACL を含める必要があります。これにより、Google Cloud Search が適切なレベルでアクセスするために必要な情報が得られます クリックします。
Content Connector SDK は、リポジトリの ACL をモデル化するために必要な一連の ACL クラスやメソッドを潤沢に提供しているため、ほとんどのリポジトリに対応できます。アイテムをインデックス登録するときは、リポジトリ内の各アイテムの ACL を分析して、Google Cloud Search の対応する ACL を作成する必要があります。リポジトリの ACL で ACL の継承といったコンセプトが用いられている場合、その ACL をモデル化するのは厄介な作業になるかもしれません。Google Cloud Search の ACL の詳細は、Google Cloud Search の ACL を参照してください。
注: Cloud Search の Indexing API がサポートしているのは単一ドメインの ACL であって、クロスドメインの ACL ではありません。こちらの
Acl.Builder
クラスを使用して、ACL を使用して各アイテムへのアクセス権を設定します。次のコード スニペットは、
フル走査のサンプルから
すべてのユーザーまたは「プリンシパル」
(getCustomerPrincipal()
)
すべてのアイテムの「リーダー」に
(.setReaders()
)
表示されます。
ACL について理解し、リポジトリに合わせて ACL を適切にモデル化する必要があります。たとえば、あるファイル システムのファイルをインデックス登録するとき、そのファイル システムである種の継承モデルが用いられているために、子フォルダが親フォルダからアクセス権を継承する場合があります。ACL の継承をモデル化するためには、Google Cloud Search の ACL で解説している追加情報が必要です。
アイテムのメタデータを設定する
メタデータは Item
オブジェクトに格納されます。Item
を作成するには、以下が必要です。
一意の文字列 ID、アイテムタイプ、ACL、URL、アイテムの最低限の値です。
次のコード スニペットは、Item
を
IndexingItemBuilder
ヘルパークラスです。
インデックス登録可能なアイテムを作成する
アイテムのメタデータを設定したら、インデックス登録可能な実際の
[
RepositoryDoc.Builder
。
次の例は、単一のインデックス登録可能なアイテムを作成する方法を示しています。
RepositoryDoc
は
実際の値を実行する ApiOperation
IndexingService.indexItem()
リクエストできます。
また、
setRequestMode()
メソッド(
RepositoryDoc.Builder
クラスを ASYNCHRONOUS
または SYNCHRONOUS
に設定してインデックス登録リクエストを指定します。
ASYNCHRONOUS
- 非同期モードでは、インデックス登録から表示までのレイテンシが長くなり、 は、インデックス登録リクエストに対する大量のスループットの割り当てに対応します。非同期モードは リポジトリ全体の初回インデックス登録(バックフィル)におすすめの方法です。
SYNCHRONOUS
- 同期モードを使用すると、インデックス登録からサービングまでのレイテンシが短縮され、
限られたスループットの割り当てに対応します。同期モードは、リポジトリの更新や変更をインデックス登録するケースで使うことをおすすめします。条件
指定しない場合、リクエスト モードはデフォルトで
SYNCHRONOUS
になります。 で確認できます。
次のステップ
必要に応じて次の手順を行います。
- (省略可)
close()
を実装する メソッドを使用して、シャットダウン前にすべてのリソースを解放できます。 - (省略可)Content Connector SDK で ID コネクタを作成する。
テンプレート クラスを使用してグラフ走査コネクタを作成する
Cloud Search インデックス登録キューの目的は、リポジトリ内の各アイテムの ID(および必要に応じてハッシュ値)を保持することです。グラフ走査コネクタがアイテム ID を Google Cloud Search インデックス登録キューを検索し、1 つずつ取得して、 説明します。Google Cloud Search はキューを維持管理し、キューの内容を比較することでアイテムのステータス(アイテムがリポジトリから削除済みかどうかなど)を確認します。Cloud Search インデックス登録キューについて詳しくは、 から Google Cloud Search インデックス登録キュー。
インデックス登録の過程で、アイテムのコンテンツがデータ リポジトリからフェッチされ、すべての子アイテムの ID がキューに push されます。コネクタによる親 ID と子 ID の処理は、すべてのアイテムが処理されるまで再帰的に進行します。
Google ドキュメントの当該セクションのコード スニペットは、GraphTraversalSample サンプルからの抜粋です。
コネクタのエントリ ポイントを実装する
コネクタのエントリ ポイントは、
main()
メソッドを使用します。このメソッドの主なタスクは、
Application
そのクラスの情報を
start()
メソッドを使用してコネクタを実行します。
電話をかける前に
application.start()
使用
IndexingApplication.Builder
クラスを使用して ListingConnector
テンプレートをインスタンス化します。「
ListingConnector
受け入れられるものは
Repository
そのオブジェクトのメソッドを実装します。
次のスニペットは、
ListingConnector
とそれに関連する Repository
をインスタンス化します。
SDK はバックグラウンドで
initConfig()
メソッド(コネクタの main()
メソッド呼び出し後の)
Application.build
。
initConfig()
メソッド:
- このメソッドを呼び出して、
Configuation.isInitialized()
メソッドをConfiguration
初期化されていないことを確認します。 - Google 提供の Key-Value で
Configuration
オブジェクトを初期化します。 あります。各 Key-Value ペアはConfigValue
Configuration
オブジェクト内のオブジェクト。
Repository
インターフェースを実装する
本サービスの唯一の目的は、
Repository
オブジェクトは、リポジトリの走査とインデックス登録を実行します。
あります。テンプレートを使用する際は、
コンテンツ コネクタを作成するための Repository
インターフェース。オーバーライドするメソッドは、使用するテンプレートと走査戦略によって異なります。対象:
ListingConnector
次のメソッドをオーバーライドします。
「
init()
メソッドを呼び出します。データ リポジトリの設定と初期化を行うには、init()
メソッドを使用します。getIds()
メソッドを呼び出します。リポジトリ内のすべてのレコードの ID とハッシュ値を取得するには:getIds()
メソッドをオーバーライドする。getDoc()
メソッドを呼び出します。インデックスのアイテムを新たに追加、更新、変更、削除するには、getDoc()
メソッドを使用します。(省略可)
getChanges()
メソッドを呼び出します。リポジトリが変更検出をサポートしている場合は、getChanges()
メソッドを使用します。このメソッドは、(お客様の構成で定義した)スケジュール済みの増分走査ごとに 1 回呼び出され、変更されたアイテムを取得してインデックス登録します。(省略可)
close()
メソッドを呼び出します。リポジトリのクリーンアップを行う必要がある場合は、close()
をオーバーライドします。 メソッドを呼び出します。このメソッドは、コネクタのシャットダウン時に 1 回呼び出されます。
これらの各メソッドは、
Repository
オブジェクトは、なんらかのタイプの ApiOperation
オブジェクトを返します。ApiOperation
オブジェクトは、単一または複数の形式でアクションを実行します。
IndexingService.indexItem()
呼び出しを行い、リポジトリの実際のインデックス登録を行います。
カスタム構成パラメータを取得する
コネクタの構成を扱う際に、コネクタの
カスタムパラメータの
Configuration
渡されます。このタスクは通常、
Repository
クラスの
init()
メソッドを使用します。
Configuration
クラスには、さまざまなデータ型を取得するためのメソッドがいくつかあります。
構成から分離できます。各メソッドは ConfigValue
オブジェクトを返します。次に、
ConfigValue
オブジェクトの
get()
メソッドを使用して実際の値を取得できます。
次のスニペットは、
FullTraversalSample
データセットを取得する方法を
Configuration
オブジェクトから 1 つのカスタム整数値を取得する:
複数の値を含むパラメータを取得して解析するには、
Configuration
クラスの型パーサー: データを個別のチャンクに解析します。
チュートリアル コネクタからの次のスニペットでは、
getMultiValue
メソッドを使用して、GitHub リポジトリ名のリストを取得します。
グラフ走査を実行する
オーバーライド
getIds()
メソッドを使用して、リポジトリ内のすべてのレコードの ID とハッシュ値を取得できます。
getIds()
メソッドはチェックポイントを受け取ります。チェックポイントは、プロセスが中断された場合に特定のアイテムからインデックス登録を再開する目的で使用します。
次に、kubectl の
getDoc()
メソッドを使用して、Cloud Search インデックス登録キュー内の各アイテムを処理します。
アイテムの ID とハッシュ値を push する
オーバーライド
getIds()
を使用してアイテム ID とその関連コンテンツのハッシュ値を
できます。その後、ID とハッシュ値のペアをパッケージ化して、Cloud Search インデックス登録キューに対する push 操作リクエストを作成します。通常、ルート(または親)の ID が最初に push され、続いて子の ID が push されます。こうしてアイテムの階層全体が処理されます。
getIds()
メソッドは、チェックポイントを受け取る(最後のアイテムを表す)
表示されます。チェックポイントは、プロセスが中断された場合に特定のアイテムからインデックス登録を再開する目的で使用します。リポジトリ内のアイテムごとに、以下の操作を行います。
getIds()
メソッドのステップ:
- 各アイテムの ID と関連ハッシュ値をリポジトリから取得する。
- 各 ID とハッシュ値のペアを
PushItems
にパッケージ化します。 - 各
PushItems
を結合して、getIds()
メソッドを使用します。なお、getIds()
は実際にはCheckpointCloseableIterable
反復処理であり、ApiOperation
各オブジェクトは、特定のインスタンスで実行される API リクエストRepositoryDoc
などのタスクをキューに push できます。
次のコード スニペットは、各アイテムの ID とハッシュ値を取得する方法を示しています。
プロンプトに
PushItems
。PushItems
とは
ApiOperation
リクエスト。アイテムを Cloud Search インデックス登録キューに push します。
次のコード スニペットは、
PushItems.Builder
クラスを使用して ID とハッシュ値を 1 つの push にパッケージ化し、
ApiOperation
。
アイテムは、Cloud Search インデックス登録キューに push 後、さらに処理されます。
各アイテムを取得して処理する
オーバーライド
getDoc()
: Cloud Search インデックス登録キュー内の各アイテムを処理します。
アイテムは、新しいアイテム、変更されるアイテム、変更されていないアイテム、ソースに存在しなくなったアイテムのいずれかです。
できます。新規または変更済みの各アイテムを取得してインデックス登録します。ソース リポジトリにもう存在しないアイテムをインデックスから取り除きます。
getDoc()
メソッドは Cloud Search Indexing からアイテムを受け取ります。
Queue。キュー内のアイテムごとに、次の手順を実行します。
getDoc()
メソッド:
Cloud Search インデックス登録キュー内のアイテムの ID がリポジトリに存在するかどうかを確認し、存在しなければアイテムをインデックスから削除する。存在する場合は、次の手順に進む。
変更済みまたは新規のアイテムをインデックス登録する:
- アクセス許可を設定する。
- インデックス登録するアイテムのメタデータを設定する。
- メタデータとアイテムを結合して、インデックス登録可能な 1 つにする
RepositoryDoc
。 - 子の ID を Cloud Search インデックス登録キューに入れて処理を続ける。
RepositoryDoc
を返します。
削除対象のアイテムを処理する
次のコード スニペットは、アイテムがインデックスに存在するかどうか確認して存在しない場合に削除する方法を示しています。
アイテムへのアクセス許可を設定する
リポジトリは、アイテムにアクセスできるユーザーまたはグループを識別するためにアクセス制御リスト(ACL)を使用します。ACL は、アイテムにアクセスできるグループまたはユーザーの ID のリストです。
リポジトリで使用する ACL を複製して、指定したユーザーのみが使用されるようにする必要があります。 アイテムにアクセスできるユーザーは、検索結果でそのアイテムを表示できます。「 アイテムをインデックス登録する際は、アイテムの ACL を含める必要があります。これにより、Google Cloud Search が適切なレベルでアクセスするために必要な情報が得られます クリックします。
Content Connector SDK は、リポジトリの ACL をモデル化するために必要な一連の ACL クラスやメソッドを潤沢に提供しているため、ほとんどのリポジトリに対応できます。アイテムをインデックス登録するときは、リポジトリ内の各アイテムの ACL を分析して、Google Cloud Search の対応する ACL を作成する必要があります。リポジトリの ACL で ACL の継承といったコンセプトが用いられている場合、その ACL をモデル化するのは厄介な作業になるかもしれません。Google Cloud Search の ACL の詳細は、Google Cloud Search の ACL を参照してください。
注: Cloud Search の Indexing API がサポートしているのは単一ドメインの ACL であって、クロスドメインの ACL ではありません。こちらの
Acl.Builder
クラスを使用して、ACL を使用して各アイテムへのアクセス権を設定します。次のコード スニペットは、
フル走査のサンプルから
すべてのユーザーまたは「プリンシパル」
(getCustomerPrincipal()
)
すべてのアイテムの「リーダー」に
(.setReaders()
)
表示されます。
ACL について理解し、リポジトリに合わせて ACL を適切にモデル化する必要があります。たとえば、あるファイル システムのファイルをインデックス登録するとき、そのファイル システムである種の継承モデルが用いられているために、子フォルダが親フォルダからアクセス権を継承する場合があります。ACL の継承をモデル化するためには、Google Cloud Search の ACL で解説している追加情報が必要です。
アイテムのメタデータを設定する
メタデータは Item
オブジェクトに格納されます。Item
を作成するには、以下が必要です。
一意の文字列 ID、アイテムタイプ、ACL、URL、アイテムの最低限の値です。
次のコード スニペットは、Item
を
IndexingItemBuilder
ヘルパークラスです。
インデックス登録可能なアイテムを作成する
アイテムのメタデータを設定したら、インデックス登録可能な実際の
[
RepositoryDoc.Builder
。
次の例は、単一のインデックス登録可能なアイテムを作成する方法を示しています。
RepositoryDoc
は ApiOperation
の一種で、実際のデータ
IndexingService.indexItem()
リクエスト。
また、
setRequestMode()
メソッド(
RepositoryDoc.Builder
クラスを ASYNCHRONOUS
または SYNCHRONOUS
に設定してインデックス登録リクエストを指定します。
ASYNCHRONOUS
- 非同期モードでは、インデックス登録から表示までのレイテンシが長くなり、 は、インデックス登録リクエストに対する大量のスループットの割り当てに対応します。非同期モードは リポジトリ全体の初回インデックス登録(バックフィル)におすすめの方法です。
SYNCHRONOUS
- 同期モードを使用すると、インデックス登録からサービングまでのレイテンシが短縮され、
限られたスループットの割り当てに対応します。同期モードは、リポジトリの更新や変更をインデックス登録するケースで使うことをおすすめします。条件
指定しない場合、リクエスト モードはデフォルトで
SYNCHRONOUS
になります。
子の ID を Cloud Search インデックス登録キューに入れる
次のコード スニペットは、現在処理中の親アイテムの子の ID をキューに入れて処理する方法を示しています。これらの ID は、親アイテムのインデックス登録後に処理されます。
次のステップ
必要に応じて次の手順を行います。
- (省略可)
close()
を実装する メソッドを使用して、シャットダウン前にすべてのリソースを解放できます。 - (省略可)Identity Connector SDK で ID コネクタを作成する。
REST API を使用してコンテンツ コネクタを作成する
以下のセクションでは、REST API を使用してコンテンツ コネクタを作成する方法を説明します。
使用する走査戦略を決める
コンテンツ コネクタの主な機能は、リポジトリを走査してそのデータをインデックス登録することです。お客様のリポジトリ内のデータの規模と配置に基づいて走査戦略を実装してください。よく使われる走査戦略は以下の 3 つです。
- フル走査戦略
リポジトリ全体をスキャンして、すべてのアイテムを無分別にインデックス登録する戦略です。フル走査は、リポジトリの規模が小さく、インデックス登録するたびに全体を走査してもオーバーヘッドを許容できる場合によく使われる戦略です。
フル走査戦略は、概ね静的で階層構造を持たないデータを含む小規模なリポジトリに向いています。変更検出が困難なリポジトリや変更検出機能をサポートしていないリポジトリで使用することもあります。
- リスト走査戦略
すべての子ノードを含むリポジトリ全体をスキャンして各アイテムのステータスを確認した後、2 回目のパスで前回のインデックス登録以降に作成または更新されたアイテムのみをインデックス登録する戦略です。リスト走査戦略は、インデックスを更新するたびに全体を走査しなくてもよい場合に、既存のインデックスを増分更新するためによく使われる戦略です。
リスト走査戦略は、変更検出が困難なリポジトリや変更検出機能をサポートしていないリポジトリで、データが階層化されておらず、扱うデータセットが非常に大規模であるようなケースに向いています。
- グラフ走査
親ノード全体をスキャンして各アイテムのステータスを確認した後、その後、コネクタは 2 回目のパスを受け取り、インデックス処理のみを ルートノードにあるアイテムは、新しいアイテムであるか、前回のインデックス登録以降に更新されています。 最後に、コネクタはすべての子 ID を渡して、子ノードのアイテムをインデックスに登録します。 更新することもできます。コネクタは、該当するアイテムがすべて処理されるまで、すべての子ノードを再帰的にスキャンします。この種の走査は、通常、ID をすべてリストすることが現実的でない階層的なリポジトリに対して使われます。
グラフ走査戦略は、一連のディレクトリやウェブページのような階層的なデータに対してクロール操作でデータを収集するケースに向いています。
で確認できます。
走査戦略を実装しアイテムをインデックス登録する
Cloud Search のインデックス登録可能なすべての要素は、Cloud Search ではアイテムと呼ばれます。 使用できます。アイテムとは、ファイル、フォルダ、CSV ファイルの行、または 作成されます。
お客様はスキーマを登録した後、次の方法で所定のインデックスを完成できます。
(省略可)
items.upload
の使用 を使用して、インデックス登録用に 100 KiB を超えるファイルをアップロードできます。小さいファイルの場合は、コンテンツを inlineContentitems.index
。(省略可)
media.upload
の使用 アップロードします。items.index
を使用してアイテムをインデックス登録する。 たとえば、スキーマが movie のオブジェクト定義を使用している場合、 という単一の ID プロバイダを このようになります。{ "name": "datasource/<data_source_id>/items/titanic", "acl": { "readers": [ { "gsuitePrincipal": { "gsuiteDomain": true } } ] }, "metadata": { "title": "Titanic", "viewUrl": "http://www.imdb.com/title/tt2234155/?ref_=nv_sr_1", "objectType": "movie" }, "structuredData": { "object": { "properties": [ { "name": "movieTitle", "textValues": { "values": [ "Titanic" ] } }, { "name": "releaseDate", "dateValues": { "values": [ { "year": 1997, "month": 12, "day": 19 } ] } }, { "name": "actorName", "textValues": { "values": [ "Leonardo DiCaprio", "Kate Winslet", "Billy Zane" ] } }, { "name": "genre", "enumValues": { "values": [ "Drama", "Action" ] } }, { "name": "userRating", "integerValues": { "values": [ 8 ] } }, { "name": "mpaaRating", "textValues": { "values": [ "PG-13" ] } }, { "name": "duration", "textValues": { "values": [ "3 h 14 min" ] } } ] } }, "content": { "inlineContent": "A seventeen-year-old aristocrat falls in love with a kind but poor artist aboard the luxurious, ill-fated R.M.S. Titanic.", "contentFormat": "TEXT" }, "version": "01", "itemType": "CONTENT_ITEM" }
フル走査を実行するには、リポジトリ全体を定期的に繰り返しインデックス登録します。リスト走査またはグラフ走査を実行するには、 リポジトリの変更を処理するためのコード
リポジトリの変更を処理する
リポジトリ内の各アイテムを定期的に収集してインデックス登録することで完全な形のインデックスを作成できます。完全な形のインデックスの作成は、インデックスを最新状態に維持するには効果的ですが、リポジトリの規模が大きい場合や階層構造を持つ場合にコストがかかる可能性があります。
インデックス登録呼び出しを使用してリポジトリ全体を毎回繰り返しインデックス登録する代わりに、Google Cloud インデックス登録キューを変更追跡メカニズムとして使用し、変更されたアイテムだけをインデックス登録する方法もあります。こちらの items.push 後続のポーリングと更新のためにアイテムをキューにプッシュします。詳細情報 キューに関する情報の詳細については、このモジュールの Google Cloud Indexing Queue。
Google Cloud Search API について詳しくは、このモジュールの Cloud Search API