Atlas Stream Processing 階層選択ガイド

初期化サージ

ストリーム プロセッサは、通常の操作中よりも初期実行中に多くのリソースを必要とする場合があります。例、プロセッサが大規模な Atlasコレクションに対して $initialSync を実行する場合、そのプロセッサは同期中に重い I/O と計算をサポートする必要があります。

このような需要の上昇を対応するには、一時的に高い階層を選択し、同期が完了し、プロセッサが新しい変更ストリームイベントのみを消費するように移行したときにプロセッサを増やすします。

パイプライン ロジック

集計パイプラインライン ロジックは、CPU とRAM消費のプライマリ ドライバーです。

• Windows: 長時間続くウィンドウでは、移動中に保持するRAMがより多く消費されます

  ドキュメント。

• カスタムロジック: Javascript$function ステージまたは複雑なグループ化

  ロジックにより、各メッセージの計算要件が増加します。

• 複合複雑さ: 追加のステートメントまたは計算が複雑なステージ

  リソース需要の潜在的な変化がより大きくなります。冗長キャパシティーを維持することで、消費量が急増しても一貫したスループットが確保されます。

インフラストラクチャ

ネットワークまたはストレージに接続する点に、ストリーム プロセッサのオーバーヘッドが増加します。

• ソースまたはシンク密度: からの読み取りまたは並列化されたへの書込み

  ソースまたは シンク（パーティションを持つApache Kafkaトピックなど）では、I/O 要件が増加します。

• データ強化:$lookup $httpsステージと ステージおよび 操作

  ストリーム内のデータを増やすには、 ネットワーク帯域幅 と接続プーリング が必要です。

• 調整: 多くのソースを統合する複雑な配置で

  と シンクの場合、ストリーム プロセッサはこれらの各ノード間でデータ フローをルーティングするハブとして機能できます。このようなプロセッサでは、SP30 および SP50 階層のより高いスループットのメリットが得られます。

逆に、高スループットのストリーム処理ワークロードでは、接続されたリソースの需要が増加する可能性があります。

• Atlas への影響: 大ボリューム、ストリームからの並列 I/O

  プロセッサは、ソースまたはシンク Atlas クラスターの読み取りまたは書込みキャパシティーを超えることができます。これによりプロセッサのレイテンシが増加するだけでなく、それらのクラスターに依存する他のワークロードがボトルネックになる可能性もあります。

  システム全体のパフォーマンスを確保するには、Atlas クラスターを、対話するプロセッサに比例して増やす。

パフォーマンスとレイテンシ

処理ロジックが単純な場合でも、パフォーマンス目的では上位階層のプロセッサが必要になる場合があります。

• 高スループット: 上位階層プロセッサほど、ストリームのサポートが向上します

  高いレートで イベントを生成します。

• 低レイテンシ SLA: 上位階層のプロセッサが提供する高並列処理により、速度が重要な場合にイベントがキューに蓄積されなくなります。特に、SP50 プロセッサは SP30 プロセッサの 4 倍のスレッドを提供します。

• データ暗号化とキャッシュ: $cachedLookupを使用してデータを増やす場合

  ストリーム間で大規模な静的参照データまたは低速変化参照データを含む場合は、キャッシュに必要なRAM を提供するために上位階層のプロセッサが優先されます。

• 複雑なシンク: 特定のシンクはよりコストのかかる

  変換、トランザクション、ファイル管理のオーバーヘッドが含まれます。これらのシンクを使用するプロセッサの場合、上位の階層は一貫したパフォーマンスとレイテンシを確保するのに役立ちます。