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 が 1000 で 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 を実装するコネクタは 1 つの走査を使用してアイテムをインデックスに登録します。インデックス登録のスループットを向上させるには、特定のアイテムのステータス（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 秒 |