一般的な処理の機能拡張

以下の調整により、多数の文書を含むコレクションの全体的なスループットを向上させることで、文書のロードと処理の開始にかかる時間が削減されます。

これらの設定は、文書にエンリッチメントが適用されない場合に最適です。 ただし、プロジェクト・タイプが異なれば、コレクションに自動的に適用されるエンリッチメントも異なります。 デフォルトでは、 「カスタム」 プロジェクト・タイプのみがエンリッチメントを適用しません。 エンリッチメントが適用されるコレクションに対して行う調整については、 エンリッチメント処理の改善 を参照してください。

20,000 以上の文書を持つコレクションに対して、以下の調整を試行してください。

• PostgreSQL ポッドのメモリー制限と sharedBuffer サイズを増やします。
• ゲートウェイ・ポッドの Java ヒープ・サイズ、メモリー、および CPU 制限の 2 倍のサイズ。
• 取り込み API ポッドの ingestion-api コンテナーのメモリー制限と Java ヒープ・サイズを 2 倍にします。
• Java ヒープ・サイズを 2 倍にして、取り込み API ポッドの取り込みコンテナーの CPU とメモリーの制限を 4 倍増やします。

以下の YAML の抜粋は、これらの変更を適用するサンプル・カスタム・リソース・パッチ・ファイルを示しています。

cat <<EOF | oc patch wd wd --type=merge --patch -
spec:
  api:
    api:
      wlpMaxHeap: 1024m
      resources:
        limits:
          memory: 2Gi
          cpu: "4"
  coreapi:
    ingestionApi:
      wlpMaxHeap: 2048m
      resources:
        limits:
          memory: 2Gi
      ingestion:
        resources:
          limits:
            cpu: "2"
            memory: 4Gi
  postgres:
    database:
      resources:
        limits:
          memory: 8Gi
      sharedBuffer: 2048MB
EOF

エンリッチメント処理の改善

コレクションにエンリッチメントが適用されると、文書を処理するためにより多くのリソースが必要になります。 一部のプロジェクト・タイプでは、エンリッチメントがコレクションに自動的に適用されます。 例えば、 「文書の取得 (Document Retrieval)」 プロジェクト・タイプを作成する場合、 「品詞 (Part of Speech)」 エンリッチメントと 「エンティティー (Entities)」 エンリッチメントがコレクションに適用されます。

Discovery のデフォルト構成では、エンリッチメントを処理するために、コレクションごとに 1 つの hdp-worker ポッドを使用します。 別々のコレクションにデータを取り込むと、各コレクションが並行して処理されます。 hdp-worker ポッドの数を増やすと、同時に処理されるコレクションの数を増やすことができます。 ただし、文書を 1 つのコレクションにのみ追加する場合、またはコレクションごとのエンリッチメントの処理を高速化する必要がある場合は、hdp-worker ポッドの数を増やしてもパフォーマンスは向上しません。 代わりに、 docproc job number パラメーター値を変更する必要があります。

同じ hdp-worker ポッドで同時に実行されるエンリッチメント・ジョブの数を増やすには、 docproc job number パラメーター値を増やします。 docproc job number 値を変更する際には注意してください。 値をゆっくり増やして、その影響を確認してください。 例えば、値を 1 から 2 に増やし、ポッド内の潜在的なメモリーの問題を監視します。 問題が発生しない場合は、値を 2 ずつ増やすことができます。 ここでも、それぞれの変更後に発生する可能性のある問題に注意してください。 メモリー不足が原因で一部の文書の取り込みが失敗し始めた場合は、 docproc job number パラメーターの値を減らすか、 hdp-worker memory パラメーターの値を増やすことができます。

ワーカー・ポッドからの結果は、索引付けのために Elasticsearch サービス・ポッドに送信されます。 エンリッチメント処理の並列処理を増やすと、より多くの文書が同時にインデクサー・ポッドに送信されます。 そのため、より大きなボリュームを処理するために、インデクサー・ポッドのサイズを増やすことが必要になる場合があります。

エンリッチメントが適用されるコレクションの取り込みを最適化するために、一般的な処理機能拡張設定に加えて、以下の調整を試すことができます。

• Java Docproc ジョブの最大メモリー・サイズと索引付け文書バッチ・サイズを 2 倍にします。
• 収集ごとに実行できる Docproc ジョブ番号を増やします。
• インデクサー・ポッドの Java ヒープ・サイズ、メモリー、および CPU の制限とレプリカを 2 倍にします。
• Elasticsearch Data Node ポッドの Java のヒープ・サイズ、メモリー、および CPU の制限とレプリカを 2 倍にします。

以下の YAML の抜粋は、これらの変更を適用するサンプル・カスタム・リソース・パッチ・ファイルを示しています。

cat <<EOF | oc patch wd wd --type=merge --patch -
spec:
  postgres:
    database:
      resources:
        limits:                               
          memory: 8Gi                         
      sharedBuffer: 2048MB                    
  hdp:
    worker:
      replicas: 6                             
      resources:
        limits:
          cpu: "16"                           
          memory: 36Gi                        
        requests:
          cpu: "6"                            
          memory: 24Gi                        
  orchestrator:
    esPublishBatchSize: 400                   
    esPublishDataSizeThreshold: "20"          
    docproc:
      maxMemory: 4g                           
      workerNum: "10"                         
  foundation:
    indexer:
      replicas: 4                             
      javaOptions: "-Xmx4096m -Xms512m"       
      resources:
        limits:
          cpu: "2"                            
          memory: 8Gi                         
  elasticsearch:
    dataNode:
      replicas: 4
      maxHeap: 8g
      resources:
        limits:
          cpu: "4"
          memory: 16Gi
EOF

Smart Document Understanding 処理の改善

Smart Document Understanding (SDU) モデルがコレクションに適用されると、文書を処理するために他の追加リソースが必要になります。 一部のプロジェクト・タイプでは、SDU モデルがコレクションに自動的に適用されます。 例えば、 「Document Retrieval for Contracts」 プロジェクト・タイプを作成すると、SDU エンリッチメントがコレクションに適用されます。

ユーザー・トレーニング済みまたは事前トレーニング済みの Smart Document Understanding (SDU) モデルが大規模なコレクションに適用される場合は、hdp-worker ポッドの数を増やして、文書の処理にかかる時間を短縮することができます。 hdp-worker ポッドを開始するには、多数のコアとメモリーが必要です。 クラスター内で使用可能なワーカー・ノードのサイズと数に対して要求されたレプリカの数を調べて、要求を処理するために十分な数のノードがあることを確認してください。

SDU モデルが適用されたコレクションに対して、以下の調整を試行します。

• 2 つの増分で hdp-worker レプリカの数を増やします。 例えば、4 から 6 に移動し、問題を監視します。

イメージ処理の改善

コレクションで光学式文字認識 (OCR) を有効にする操作は、コストのかかる操作です。 OCR をコレクションに適用するのは、文書内の関心領域がイメージ内にあることが分かっている場合のみにしてください。 文書にイメージが含まれていない場合、またはイメージのスタイルがほとんどである場合、それらのイメージは、関連するテキストがないロゴまたはピクチャーです。例えば、コレクションで OCR を無効にします。