Atlas triggers はアプリケーションとデータベースロジックを実行します。 trigger は、イベントに応答したり、事前定義されたスケジュールを使用したりできます。trigger を作成、変更、または削除するには Project Owner ロールが必要です。
trigger は、構成された型のイベントをリスニングします。各 trigger は特定の Atlas Function にリンクします。trigger は、構成に一致するイベントを検出すると、起動します。trigger は、このイベント オブジェクトをリンクされた関数への引数として渡します。
trigger は、次の場合に起動する可能性があります。
特定のコレクションにおける特定の操作型。
スケジュールされた時刻。
Atlas は、各 trigger の最新の実行時間を追跡し、各イベントが少なくとも 1 回は処理されることを保証します。
trigger の種類
Atlas は、次のタイプの trigger をサポートしています。
データベース Triggers は、ドキュメントの挿入、変更、または削除に応答します。リンクされた MongoDB コレクションごとにデータベース Triggers を構成できます。
スケジュールされた Triggers は、事前定義されたスケジュールに従って機能を実行します。
制限
Atlas Function 制限の適用
Triggers は Atlas Function を呼び出します。つまり、すべての Atlas 関数と同じ制約があります。
イベント処理のスループット
容量が利用可能になったときにプロセス イベントを Triggers します。Triggers の容量は、イベント順序の構成により異なります。
順序付き Triggers は、変更ストリームからのイベントを 1 つずつ順番に処理します。次のイベントは、前のイベントの処理が完了した後にのみ処理を開始します。
順序付けされていない Triggersは、複数のイベントを同時に処理できます。デフォルトでは、一度に最大 10,000 件まで処理できます。Trigger データソースが M10+ Atlas クラスターの場合、10,000 の同時イベントのしきい値を超えるように、順序付けられていない個々の Triggers を構成できます。詳しくは、「最大スループット Triggers」を参照してください。
trigger の容量は、スループットや保証された実行速度を直接測定するものではありません。代わりに、trigger が一度に処理できるイベントの最大数のしきい値です。実際には、trigger がイベントを処理できる速度は、trigger 関数の実行時ロジックと、特定の時間枠内に受信するイベントの数によって異なります。
trigger のスループットを向上させるには、次の操作を試してください。
trigger 関数の実行時の動作を最適化します。たとえば、ネットワーク呼び出しの数を減らすことができます。
trigger のプロジェクション フィルターを使用して、各イベント オブジェクトのサイズを縮小します。最高のパフォーマンスを得るには、各変更イベントのサイズを 2 KB 以下に制限します。
トリガーが処理するイベントの数を減らすには、一致フィルターを使用します。たとえば、特定のフィールドが変更された場合にのみ実行したい操作がある場合、すべてのアップデート イベントをマッチングして関数コードでフィールドの変更を確認する代わりに、トリガーの一致フィルターを使用することで、アップデート イベントの
updateDescription.updatedFieldsオブジェクトにフィールドが含まれている場合にのみ実行できます。
Triggers の数は利用可能な変更ストリームの数を超えることはできません
Atlas はデータベース trigger の合計数を制限します。 この制限は Atlas クラスターのサイズにより異なります。
各 Atlas クラスター階層には、サポートされる変更ストリームの最大数があります。データベース Triggers には独自の変更ストリームが必要です。データベース Triggers は、使用可能な変更ストリームの数を超えることはできません。
Atlas 層でサポートされている変更ストリームの数の詳細については、「サービス制限 」ページを参照してください。
重複イベントを診断する
通常の Triggers 操作中、Triggers は重複したイベントを送信しません。ただし、何らかの障害またはエラーが発生した場合、Triggers は重複したイベントを配信することがあります。以下のような場合、Triggers イベントが重複して表示されることがあります：
イベントの処理と追跡を担当するサーバーに障害が発生します。この障害により、サーバーは永続的または長期のストレージ システムに進行状況を記録できなくなり、最新のイベントの一部を処理したことを「忘れる」ことになります。
イベント 1 から 10 が同時に送信される順序なし処理を使用します。イベント 9 が失敗して trigger が停止した場合、システムがイベント 9 から再開すると、イベント 10 などのイベントが再度処理される可能性があります。システムがイベントの順序に厳密に従わず、すでに処理されたイベントを再処理する可能性があるため、これにより重複が発生する可能性があります。
trigger イベントが重複していることに気付いた場合は、 trigger ログで中断された trigger やサーバー障害がないか確認してください 。