Background workers ================== バックグラウンドワーカーは、 EDB Postgres AIの非同期AIパイプラインの実行エンジンです。標準のデータベーストランザクションをブロックすることなく、大量のデータを処理できます。 バックグラウンドワーカーは、\ ``auto_processing => 'Background'`` でパイプラインが作成または更新されると、自動的にアクティブ化されます。バックグラウンドモードを有効にする前に、必要なPostgresサーバー設定が設定されていることを確認します。 Postgresの前提条件 ------------------ バックグラウンドパイプラインを実行する前に、2つの\ ``postgresql.conf`` 設定を設定する必要があります。 shared_preload_libraries ^^^^^^^^^^^^^^^^^^^^^^^^ バックグラウンドワーカーを起動する前に、\ ``postgresql.conf`` で\ ``shared_preload_libraries = 'aidb'`` を設定する必要があります。これはAIDBのインストール中に構成されます。 :ref:`Configuring AIDB ` を参照してください。パイプラインでバックグラウンドモードを有効にする前に、設定されていることを確認してください。 max_worker_processes ^^^^^^^^^^^^^^^^^^^^ バックグラウンドモードの各パイプラインは、1つの専用のPostgresバックグラウンドワーカープロセスを必要とします。 ``max_worker_processes`` 設定は、クラスター全体で許可されるバックグラウンドワーカープロセスの数を制御します。 デフォルト値は\ ``8`` です。複数のバックグラウンドパイプラインを実行する予定がある場合は、この値を増やします。 .. code:: ini max_worker_processes = 20 この設定を変更した後、Postgresを再起動します。現在の値を確認するには .. code:: sql SHOW max_worker_processes; ``max_worker_processes`` が使い果たされると、新しく作成されたバックグラウンドパイプラインはワーカーを起動せず、容量が解放されるまでサイレントに処理をスキップします。 コア機能 -------- - **非同期実行** パイプラインがバックグラウンドモードに設定されている場合、処理はユーザーセッションとは無関係に発生します。この方法により、ソーステーブルのクエリまたはデータ変更が、生成またはOCRタスクの埋め込みによって遅延されません。 - **バッチ処理** バックグラウンドワーカーは、レコードを構成可能なバッチサイズにグループ化します。これにより、特にGPUベースのモデルまたはリモートAIサービスAPIと対話する場合、スループットが最適化されます。 - **パラレルオペレーション** 各バッチ内で、ワーカーはパイプラインステップデータの取得、埋め込み計算、およびストレージをパラレル操作として実行して、パフォーマンスを最大化します。 - **継続ポーリング** ワーカーは、定義された\ ``background_sync_interval`` に基づいて、変更がないかソースを継続的に監視します。 変更検出 -------- バックグラウンドワーカーは、特定の検出ロジックを使用してさまざまなソースタイプを処理します。 - **テーブルソース** 軽量トリガーは、挿入、更新、削除などの変更イベントをキャプチャし、バックログに配置します。バックグラウンドワーカーは、次のインターバルでこのバックログを処理します。 - **ボリュームソース** バックグラウンドワーカーは、外部ストレージのスキャンを実行します。ファイルの\ ``last_modified`` タイムスタンプを状態テーブルと比較して、新しいドキュメントまたは変更されたドキュメントを識別します。 構成とコンストレイン -------------------- 必須 ^^^^ - **Postgres前提条件** バックグラウンドワーカーには、\ ``shared_preload_libraries = 'aidb'`` と\ ``postgresql.conf`` に十分な\ ``max_worker_processes`` 値が必要です。このページの :ref:`Postgresの前提条件 ` を参照してください。 オプションのチューニング ^^^^^^^^^^^^^^^^^^^^^^^^ **``background_sync_interval``** は、ワーカーが新しいデータまたは変更されたデータをポーリングする頻度を制御します。これは、 ``postgresql.conf`` ではなく、\ ``aidb.create_pipeline()`` または\ ``aidb.update_pipeline()`` を介してパイプラインごとに構成されます。 .. code:: sql SELECT aidb.create_pipeline( name => my_pipeline, source => my_table, auto_processing => Background, background_sync_interval => 30 seconds, ... ); デフォルトの間隔は、ほとんどのテーブルソースに適しています。 AWS S3のようなクラウドオブジェクトストアによってバッキングされるボリュームソースの場合、各スキャンではリストオペレーションが発生し、コストまたはレート制限に影響を与える可能性があります。これらの場合、より長い間隔を検討します。 .. code:: sql SELECT aidb.update_pipeline( my_s3_pipeline, background_sync_interval => 1 day ); ``background_sync_interval`` は、Postgres間隔値\ ``'5 minutes'`` 、\ ``'1 hour'`` 、\ ``'1 day'`` などを受け入れます。 モニタリングとオブザーバビリティ -------------------------------- ``aidb.pipeline_metrics`` ビュー ``aidb.pipem`` としてもアクセスを使用して、バックグラウンドワーカーのステータスと状態を追跡できます。主要なメトリックには次のものが含まれます。 - **Table- unprocessed rows** テーブルソースの場合、まだ処理されていない行の数。 - **ボリューム-スキャン完了** ボリュームソースの場合、完了したフルスキャンの数。 - **Count (source records)** ソース内のレコードの合計数。 - **Count (destination records)** 宛先のレコードの合計数。 - **Status** 現在のパイプラインのステータス。