PostgreSQL TRIGGERのスケーリング

Postgresがメカニズムのスケールをトリガーする方法

PostgreSQLを大規模にインストールしており、ログテーブルとTRIGGERを使用してイベントベースのシステムを実装しようとしています。

基本的に、UPDATE / INSERT / DELETE操作の通知を受け取る各テーブルにTRIGGERを作成します。このトリガーが起動されると、ログテーブルに新しい行を追加する（イベントをエンコードする）関数を実行し、その後、外部サービスからポーリングします。

Postgres TRIGGERを使用する前に、それらがどのようにスケーリングするかを知りたいと思います。単一のPostgresインストールでいくつのトリガーを作成できますか？クエリのパフォーマンスに影響しますか？これを試す前に誰かがしましたか？

基本的に、UPDATE / INSERT / DELETE操作の通知を受け取る各テーブルにTRIGGERを作成します。このトリガーが起動されると、ログテーブルに新しい行を追加する（イベントをエンコードする）関数を実行し、その後、外部サービスからポーリングします。

これは、トリガーのかなり標準的な使用法です。

Postgres TRIGGERを使用する前に、それらがどのようにスケーリングするかを知りたいと思います。単一のPostgresインストールでいくつのトリガーを作成できますか？

それらを作成し続けると、最終的にはディスク容量が不足します。

トリガーに特定の制限はありません。

PostgreSQLの制限はaboutページに記載されています。

クエリのパフォーマンスに影響しますか？

トリガーの種類、トリガー言語、およびトリガーの動作によって異なります。

BEFORE ... FOR EACH STATEMENT何もしない単純なPL / PgSQL トリガーのオーバーヘッドはほぼゼロです。

FOR EACH ROWトリガーは、FOR EACH STATEMENTトリガーよりもオーバーヘッドが高くなります。明らかに、影響を受ける行カウントでのスケーリング。

AFTERトリガーはBEFORE、ステートメントが作業を完了するまでキューに入れてから実行する必要があるため、トリガーよりも高価です。キューが大きくなると（少なくとも9.4以下で、将来変更されるAFTER可能性があります）、ディスクに流出しません。そのため、巨大なトリガーキューにより利用可能なメモリがオーバーランし、ステートメントが中断します。

NEW挿入/更新の前に行を変更するトリガーは、DMLを実行するトリガーよりも安価です。

あなたが望む特定のユースケースは、FOR EACH STATEMENTトリガーが仮想OLDとNEWテーブルを見ることができるPostgreSQL 9.5（幸運なら）に移行するかもしれない進行中の拡張でより良く実行するでしょう。これは現在のPostgreSQLバージョンでは不可能なので、FOR EACH ROW代わりにトリガーを使用する必要があります。

これを試す前に誰かがしましたか？

もちろん。監査、健全性チェックなどとともに、トリガーのかなり標準的な使用法です。

あなたはに見たいと思うでしょうLISTENし、NOTIFYタスクテーブルへの変更が発生したとき、あなたの労働者を覚ますための良い方法のために。

トリガーから外部システムと直接対話することを避けることで、すでに最も重要なことを行っています。これは、パフォーマンスと信頼性に問題がある傾向があります。多くの場合、トリガーから直接メールを送信するなどのことをしようとしますが、これは悪いニュースです。

少し遅れた答えですが、将来の読者には役立つかもしれません

現在（10、11、12バージョン）、同じデータを2回保存する必要はありません（PGによるWALと手動で）。Postgre Logical Decodingの仕組み（論理複製と同じ）を使用して、データのすべてまたは一部の変更を追跡できます（または、それらのイベントをkafkaなどのキューに送信して後で分析できます）