Marklogic 4.2.9 サーバーで CPF - Content Processing Framework を有効にすることの影響を理解したいと思いました。3 TB のサイズの運用データベースがあり、いくつかのアクションを実行する必要があるさまざまなコンテンツの強化とコンテンツの削除タスクを検討しています。以前のプロジェクトで CFP パイプラインの作成に取り組んできましたが、現在のプロジェクトでは DB で現在 CPF が無効になっています。私が理解したかったのは、この DB で CPF を有効にした場合、1. Marklogic のメモリ使用量、2. ディスク容量、3. すべてのパフォーマンス、4. IO などにどのような影響があるかということです。作成しようとしているパイプラインはDBに存在するすべて/任意のドキュメントに影響を与えます。
助けてくれてありがとう！！！
@mblakeleは、memとdiskへの影響を非常にうまくカバーしていると思います。しかし、CPFがどのように機能するかについていくつかの言葉を追加したいと思います。これは、パフォーマンスがCPFによって一般的にどのように影響を受けるかを助ける可能性があります。
CPFは、MarkLogicのトリガーメカニズムに依存しています。ドキュメントの挿入、更新、および削除は、初期ステータス遷移を伴うCPF処理をアクティブにします。各アクションにより、追加のステータス遷移が発生します。各ステータス遷移には、実際のアクションモジュールのxdmp：invokeを実行するCPF内部コードを呼び出して、コミット後トリガーの実行が含まれます。したがって、100個のドキュメントを挿入する単一のトランザクションがある場合、これにより、100個のコミット後のタスクがスターターのタスクサーバーキューにキューイングされます。また、xdmp：invokesにより、さらに100個のタスクがキューに入れられるのではないかと心配しています。ドキュメントが平均して3つのステータスを通過する場合、その数は少なくとも3倍になります。
つまり、CPFはタスクサーバーのキューに大きな影響を与えます。実際にパフォーマンスに影響を与える範囲は、タスクサーバーをすでに使用している度合いによって異なります。タスクサーバー上の非CPFタスクは、CPFタスクによって遅延されます。一方、現時点で実際にタスクサーバーを使用していない場合は、これについてあまり気付かない可能性があります。アプリサーバーリクエストは、個別に処理されるアプリサーバーキューで実行されます。
もう1つは、CPFがドキュメントを個別に処理することです。これは、低速で復元力のあるバックグラウンド処理に最適です。ただし、速度が必要な場合は、ドキュメントのバッチのトランザクションを作成する方が適切です。
HTH！
すでにmaintain-last-modified有効にしている場合、メモリとディスク容量への影響は最小限になります。が無効になっている場合maintain-last-modified、CPF はドキュメントが処理されると新しいプロパティ フラグメントを作成します。これにより、追加のメモリとディスク領域を使用することが期待できます。おそらく、ドキュメントごとに約 100 バイトのメモリと 1 キロバイトのディスク領域が使用されます。余分なフラグメントは、I/O と全体的なパフォーマンスにも影響を与える可能性がありますが、その範囲を予測するには、アプリケーションとそのクエリをより深く理解する必要があります。