Google Cloud Search SDK には、すべてのコネクタで使用される Google 提供構成パラメータが複数含まれています。これらの設定を調整する方法を知っていれば、データのインデックス作成を効率化できます。このガイドでは、インデックス登録中に発生する可能性のある問題と、その解決に使用される設定について説明します。
FullTraversalConnector のインデックス登録のスループットが低い
次の表に、FullTraversalConnector のスループットを改善するための構成設定を示します。
| 設定 | 説明 | デフォルト | 試行する構成変更 |
|---|---|---|---|
traverse.partitionSize |
追加の APIOperation() を取得する前にバッチで処理する ApiOperation() の数。SDK は、追加のアイテムを取得する前に、現在のパーティションが処理されるまで待機します。この設定は、使用可能なメモリの量に依存します。50 や 100 などのようにパーティション サイズを小さくすると、必要なメモリは少なくなりますが、SDK の代わりに、より長く待機する必要があります。 |
50 | 使用可能なメモリが多い場合は、partitionSize を 1, 000 以上に増やしてみてください。 |
batch.batchSize |
バッチにまとめられるリクエストの数。パーティショニングの最後に、SDK は、バッチにまとめられたすべてのリクエストがパーティションから処理されるまで待機します。バッチが大きければ大きいほど、待機時間が長くなります。 | 10 | バッチサイズを小さくしてみてください。 |
batch.maxActiveBatches |
同時に実行することが許容されるバッチの数。 | 20 | batchSize を減らす場合は、次の式に従って maxActiveBatches を上げます。maxActiveBatches = (partitionSize / batchSize）+ 50。たとえば、partititionSize が 1, 000 で batchSize が 5 の場合、maxActiveBatches は 250 にする必要があります。余分な 50 は、再試行リクエストのためのバッファーです。この増加により、コネクタはブロックせずにすべてのリクエストをバッチにまとめることができます。 |
traverse.threadPoolSize |
並列処理を可能にするためにコネクタが作成するスレッドの数。1 つのイテレータはオペレーション（通常は RepositoryDoc オブジェクト）を順次取得しますが、API 呼び出しは threadPoolSize 個のスレッドを使用して並列で処理します。各スレッドでは一度に 1 つのアイテムが処理されます。デフォルトの 50 では、最大 50 個のアイテムのみが同時に処理され、個々のアイテム（インデックス登録リクエストを含む）の処理には約 4 秒かかります。 |
50 | threadPoolSize を 10 の倍数に増やしてみてください。 |
最後に、setRequestMode() メソッドを使用して API リクエスト モード（ASYNCHRONOUS または SYNCHRONOUS）を変更します。
構成ファイルのパラメータの詳細については、Google 提供の構成パラメータをご覧ください。
ListTraversalConnector のインデックス登録のスループットが低い
デフォルトでは、ListTraversalConnnector を実装するコネクタは、単一のトラバーサーを使用してアイテムをインデックスに登録します。インデックス登録のスループットを向上させるには、特定のアイテム ステータス（NEW_ITEM、MODIFIED など）に焦点を当てた独自の構成を持つ複数の走査を作成します。次の表に、スループットを向上させるための構成設定を示します。
| 設定 | 説明 | デフォルト | 試行する構成変更 |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | 1 つ以上の個別の走査を作成します。t1, t2, t3, ... は、それぞれの一意の名前です。各名前付き走査には、走査の一意の名前（traversers.t1.hostload、traversers.t2.hostload など）を使用して識別される独自の設定セットがあります。 | 1 つの走査 | この設定を使用して、走査を追加します。 |
traversers.t1.hostload = n | アイテムを同時にインデックス登録するために使用するスレッド数 n を識別します。 | 5 | リポジトリにかかる負荷の量に基づいて n を調整してみてください。10 以上の値から始めます。 |
schedule.pollQueueIntervalSecs = s | 再ポーリングまでの待機時間 s を識別します。API がポーリング レスポンスでアイテムを返す限り、コンテンツ コネクタはアイテムのポーリングを続行します。ポーリング レスポンスが空の場合、コネクタは s 秒待ってから再試行します。この設定は、ListingConnector によってのみ使用されます。 | 10 | 1 に下げてみてください。 |
traverser.t1.pollRequest.statuses = status1, status2, … | インデックスに登録するアイテムのステータス（status1、status2、…）を指定します。たとえば、status1 を NEW_ITEM に設定し、status2 を MODIFIED に設定すると、これらのステータスのアイテムのみをインデックスに登録するようトラバーサー t1 に指示します。 | 1 つの走査がすべてのステータスをチェックします。 | さまざまな走査がさまざまなステータスをポーリングするようにしてみてください。 |
構成ファイルのパラメータの詳細については、Google 提供の構成パラメータをご覧ください。
大きいファイルのアップロード中に SDK のタイムアウトや割り込みが発生する
サイズの大きいファイルのアップロード中に SDK のタイムアウトや中断が発生する場合は、traverser.timeout=s（s = 秒数）を使用してタイムアウトを長く指定します。この値は、ワーカー スレッドがアイテムを処理するために必要な時間を示します。SDK でのデフォルトのタイムアウトは、トラバーサー スレッドで 60 秒です。また、個々の API リクエストのタイミングがタイムアウトする場合は、次の方法でリクエスト タイムアウト値を増やします。
| リクエスト タイムアウトのパラメータ | 説明 | デフォルト |
|---|---|---|
indexingService.connectTimeoutSeconds |
インデックス登録 API リクエストの接続タイムアウト。 | 120 秒 |
indexingService.readTimeoutSeconds |
インデックス登録 API リクエストの読み取りタイムアウト。 | 120 秒 |