Postgresで変更を捕捉する方法いろいろ

• この記事では、Postgresデータベースの変更を捕捉するさまざまな方法について論じています。
• Sequinという企業は、SalesforceやHubSpotのようなサードパーティAPIからデータを同期し、開発者が自分たちのPostgresデータベースを使ってAPIデータを構築できるようにしています。
• Postgresは、テーブルの変更に基づいてワークフローをトリガーしたり、他のデータストア、システム、またはサービスへリアルタイムでデータをストリーミングしたりするなど、移動中のデータを捕捉するための複数の選択肢を提供します。
• 最も簡単なアプローチは、Postgresのプロセス間通信機能であるListen/Notifyを使うことです。これはpublish-subscribeパターンの実装ですが、「最大1回」の配信セマンティクスや、ペイロードサイズが8000バイトに制限されるといった制約があります。
• 別の方法はテーブルを直接ポーリングすることで、この場合は各テーブルに、行が更新されるたびに更新されるupdated_atカラム、またはそれに類するものが必要です。しかしこの方法では、行が削除されたことを検知できず、差分も得られません。
• Postgresは、別のPostgresデータベースへのストリーミングレプリケーションをサポートしており、これをアプリケーションの変更を捕捉するために利用できます。ただし、この方法は複雑で、postgresql.confを調整する必要があるかもしれません。
• 変更は、変更内容を記録する監査テーブルからも捕捉できます。このアプローチはレプリケーションスロットを使う方法に似ていますが、より手動寄りです。
• 外部データソースへの読み書きを可能にするPostgresの機能である外部データラッパー（FDW）もあります。ただし、この方法が推奨されるのは非常に限定的な状況だけです。
• 結論として、Postgresで変更を捕捉する最善の方法はユースケースによって異なります。Listen/Notifyは重要度の低いイベントの捕捉に向いており、変更のポーリングは単純なユースケースに対する直感的な解決策で、レプリケーションは堅牢な解決策として最良の選択です。レプリケーションが難しすぎるなら、監査テーブルが優れた中間的解決策になるかもしれません。

[GN⁺]

Hacker Newsの意見

• この記事では、人気のデータベースシステムであるPostgresで変更を捕捉するさまざまな方法について議論しています。
• あるコメント投稿者は、30年以上使われてきた手法であるトリガーと履歴テーブル（監査テーブル）を使って変更を捕捉することを強く推奨しています。
• その投稿者は、この手法の実装方法に関するガイドへのリンクを示し、アプリケーション層の履歴追跡ライブラリを使うことに警鐘を鳴らしています。
• 別の投稿者は、特定時点でのテーブルの状態を見られるTemporal Tablesパターンについて、良い経験を共有しています。
• また別の投稿者は、"pgaudit"という監査テーブルを生成する実績ある拡張機能を使うことを提案しています。
• 一部の投稿者は、updated_at列をポーリングするような特定の方法に潜むリスクについて議論しています。
• Elixir & Postgresユーザー向けに、WALの変更をリッスンするライブラリへの言及もあります。
• 何人かの投稿者は、この分野には革新が必要だと述べ、Postgresはクエリ結果を段階的にプッシュする機能によって恩恵を受けられるだろうと提案しています。
• ある投稿者は、レプリケーションを使って変更を捕捉することのリスクについて警告し、Postgresがデータの消費を停止すると、取りこぼしたデータをディスクがいっぱいになるまで保存し続ける可能性があると述べています。
• 同じ投稿者は、ポーリングを使うとしてもupdated_atの代わりにtxidを保存することを提案しています。
• この議論は、データの世界における一つの側面、つまりクエリ結果を段階的にプッシュするすっきりした解決策が必要だという点を浮き彫りにしています。