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 |
並列処理を可能にするためにコネクタが作成するスレッドの数。単一のイテレータはオペレーション（通常は 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 = 秒数）。この値は、ワーカー スレッドが 1 つのアイテムをどれだけの時間で処理する必要があるかを識別します。SDK のデフォルトのタイムアウトは、走査スレッドでは 60 秒です。さらに、個々の API リクエストがタイムアウトする場合は、次の方法を使用して、リクエスト タイムアウトの値を増やします。
| リクエスト タイムアウトのパラメータ | 説明 | デフォルト |
|---|---|---|
indexingService.connectTimeoutSeconds |
インデックス登録 API リクエストの接続タイムアウト。 | 120 秒 |
indexingService.readTimeoutSeconds |
インデックス登録 API リクエストの読み取りタイムアウト。 | 120 秒 |