DocsPricingBlog
Contact Us
Log inSign up for FREE
Back to Tech Articles

PostgreSQLのLISTEN/NOTIFYを活用したリアルタイムアプリケーション構築：軽量な代替手段

Sep 13, 2025
# Misc

Daniel Hayes

Full-Stack Engineer · Leapcell

This post is also available in English, 한국어, and Deutsch
Cover of "PostgreSQLのLISTEN/NOTIFYを活用したリアルタイムアプリケーション構築：軽量な代替手段"

PostgreSQLのLISTEN/NOTIFYによるリアルタイムアプリケーション構築

今日の急速に変化するデジタル世界では、リアルタイム機能は魅力的なユーザーエクスペリエンスの基盤となっています。共同ドキュメント編集、インスタントチャットアプリケーション、ライブダッシュボードなど、変化に即座に反応できる能力が最も重要です。伝統的に、開発者はこのような応答性を実現するためにRedis Pub/SubやKafkaのような専用のメッセージングシステムに頼ってきました。これらのツールは強力でスケーラブル、そして広く採用されていますが、追加のインフラ、メンテナンスのオーバーヘッド、そして複雑さを伴います。既存のデータベース中心のアプリケーションに、よりシンプルで軽量な方法でリアルタイム機能を直接統合することができればどうでしょうか？この記事では、PostgreSQLのしばしば過小評価されているLISTEN/NOTIFYメカニズムに焦点を当て、外部メッセージブローカーを必要とせずにリアルタイム機能を構築するための強力でエレガントな代替手段としての利用を擁護します。

コアコンセプトの理解

実践に移る前に、このアプローチの中心となるPostgreSQLの主要機能について明確に理解しましょう。

  • LISTEN: このSQLコマンドは、データベースクライアントが特定の「チャネル」での通知を受信するために登録するために使用されます。クライアントは同時に複数のチャネルをリッスンできます。
  • NOTIFY: このSQLコマンドは、指定されたチャネルを現在LISTENしているすべてのクライアントに通知を送信します。オプションで追加データを含む「ペイロード」文字列（PostgreSQL 9.0以降では最大8000バイト）を含めることができます。
  • トリガー: データベーストリガーは、テーブルで特定のアクション（例：INSERT、UPDATE、DELETE）が発生したときに自動的に実行される特別な種類のストアドプロシージャです。トリガーを利用して、関連データが変更されるたびに自動的に通知を送信します。
  • チャネル: 通知が送信および受信される名前付きの「トピック」または「カテゴリ」。クライアントはチャネルをLISTENし、NOTIFYはそのチャネルにメッセージを送信します。

本質的に、LISTEN/NOTIFYはPostgreSQL内で同期型のチャネルベースのメッセージングシステムを提供します。NOTIFYコマンドが実行されると、現在接続されており、LISTENしているすべてのクライアントは、次にクエリを処理する際、または非同期通知ハンドラが呼び出されたときに通知を受け取ります。

動作原理

中心的なアイデアは、データベーストリガーを使用して、リアルタイム機能に関連するデータが変更されたときに自動的にクライアントにNOTIFYすることです。

  1. データ変更: アプリケーションは、テーブルに対してINSERT、UPDATE、またはDELETE操作を実行します。
  2. トリガー発動: そのテーブルの定義済みのAFTERトリガーが変更を検出します。
  3. 通知送信: トリガーはNOTIFYコマンドを実行し、特定のチャネルにメッセージを送信します。これには、変更に関する詳細（例：影響を受けたレコードのID、操作の種類）が含まれる場合があります。
  4. クライアント受信: そのチャネルをPostgreSQL接続でLISTENしているアプリケーションクライアントは、誰でも通知を受信します。
  5. クライアント反応: クライアントは、通知を処理します。たとえば、UIコンポーネントをリフレッシュしたり、キャッシュを無効にしたり、さらなるアクションを開始したりします。

これにより、データ変更と通知配信が緊密に結合され、リアルタイム更新が権威あるデータソースによって直接駆動されることが保証されます。

実装例

新しい製品の追加を表示するリアルタイムダッシュボードを構築する簡単な例でこれを説明しましょう。

1. データベースセットアップ

まず、productsテーブルを作成します。

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

次に、新しい製品が挿入された後に実行されるトリガー関数を作成します。

CREATE OR REPLACE FUNCTION notify_new_product()
RETURNS TRIGGER AS $$
BEGIN
    PERFORM pg_notify('new_product_channel', NEW.id::text);
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

ここで、pg_notifyはNOTIFYコマンドによって使用される基盤となる関数です。new_product_channelチャネルには、新しい製品のIDをペイロードとしてテキスト形式で送信します。

最後に、このトリガー関数をINSERT操作のためにproductsテーブルにアタッチします。

CREATE TRIGGER product_insert_trigger
AFTER INSERT ON products
FOR EACH ROW
EXECUTE FUNCTION notify_new_product();

2. クライアントサイド実装（Python例）

次に、Pythonクライアントがこれらの通知をどのようにLISTENできるか見てみましょう。ここでは、Pythonで広く利用されているPostgreSQLアダプターであるpsycopg2ライブラリを使用します。

import psycopg2
import select
import json
import time

# データベース接続情報
DB_PARAMS = {
    'host': 'localhost',
    'database': 'your_database',
    'user': 'your_user',
    'password': 'your_password'
}

def listen_for_notifications():
    conn = None
    try:
        conn = psycopg2.connect(**DB_PARAMS)
        conn.autocommit = True # LISTEN/NOTIFYには重要
        cursor = conn.cursor()

        # チャネルをリッスン
        cursor.execute("LISTEN new_product_channel;")
        print("新しい製品通知をリッスンしています...")

        while True:
            # 通知をチェックします。timeout=1は1秒ごとにチェックすることを意味します。
            if select.select([conn], [], [], 1) == ([conn], [], []):
                conn.poll()
                while conn.notifies:
                    # 最初の通知を取得
                    notify = conn.notifies.pop(0) 
                    product_id = notify.payload
                    print(f"チャネル '{notify.channel}' でペイロード: '{product_id}' を持つ通知を受信しました")
                    # 実際のアプリでは、製品詳細を取得してUIを更新します
                    fetch_product_details(product_id)
        # select.selectが完全にブロックしなかった場合にビジーウェイトを防ぐために、短いスリープを追加します
            time.sleep(0.1)

    except Exception as e:
        print(f"エラーが発生しました: {e}")
    finally:
        if conn:
            conn.close()
            print("接続を閉じました。")

def fetch_product_details(product_id):
    # この関数は通常、新しい製品の詳細を取得するためにデータベースにクエリを実行します
    # その後、WebSocketなどを介してフロントエンドにプッシュします。
    print(f"  --> 製品ID: {product_id} の詳細を取得し、ダッシュボードを更新します...")
    # 例: 実際のアプリケーションでは、データベースから完全な製品オブジェクトをクエリする場合があります。
    # with psycopg2.connect(**DB_PARAMS) as conn:
    #     with conn.cursor() as cur:
    #         cur.execute("SELECT name, price FROM products WHERE id = %s;", (product_id,))
    #         product_data = cur.fetchone()
    #         print(f"    製品詳細: 名前={product_data[0]}, 価格={product_data[1]}")

if __name__ == "__main__":
    listen_for_notifications()

テスト方法:

  1. Pythonスクリプトを別のターミナルで実行します。
  2. 別のターミナルでPostgreSQLデータベースに接続し、新しい製品を挿入します。 
    INSERT INTO products (name, price) VALUES ('E-Book Reader', 129.99);
    Pythonスクリプトは、新しい製品通知を示唆する出力（新しい製品通知を受信しました）を即座に表示するはずです。

ユースケースと利点

最適なユースケース：

  • リアルタイムダッシュボード: データ変更（例：新しい注文、サポートチケット、センサー readings）に応じてチャートとメトリクスを更新します。
  • キャッシュ無効化: 基盤となるデータベースレコードが更新されたときに、アプリケーションサーバーにキャッシュされたデータを無効にするよう通知します。
  • ユーザー通知: 関連イベント（例：チャットでの新しいメッセージ、ステータスの更新）に対してプッシュ通知またはアプリ内アラートを送信します。
  • サービス間通信（軽量）: PostgreSQLを共有するマイクロサービスの場合、LISTEN/NOTIFYは、低ボリュームでデータベース駆動のイベントのためのシンプルなイベントバスとして機能します。
  • ワークフローのトリガー: データベースイベントに基づいて下流のプロセスを開始します。

利点：

  • シンプルさとゼロセットアップ: 管理すべき外部依存関係やインフラストラクチャはありません。PostgreSQLに組み込まれています。
  • 低遅延: 通知は既存のデータベース接続を介して直接配信され、多くの場合、非常に低い遅延で配信されます。
  • トランザクション整合性: トランザクション内で送信された通知は、トランザクションが正常にコミットされた場合にのみ配信されます。これにより、データの一貫性が保証されます。
  • データローカリティ: 変更と通知は緊密に結合され、データベースを単一の真実の情報源として活用します。
  • 習熟性: SQLとトリガーに慣れている開発者は、すぐに適応できます。
  • コスト効率: 既存のデータベースリソースを活用することで、インフラストラクチャコストを削減します。

制限事項と考慮事項

強力ですが、LISTEN/NOTIFYには制限があります。

  • 永続性なし: クライアントがリッスンしていない場合、通知はキューイングまたは保存されません。クライアントが切断して再接続しても、オフライン中に送信された通知は受信できません。
  • 特定のクライアントへの配信保証なし: 通知は、特定のクライアントではなく、チャネル上のすべてのリスナーにブロードキャストされます。
  • ペイロードサイズの制限: 8000バイトのペイロード制限は、通常、IDまたは小さなJSONスニペットのみを送信することを意味します。必要に応じてクライアントが完全な詳細を取得する必要があります。
  • スケーラビリティ: 非常に高ボリュームのグローバル規模のメッセージングの場合、Kafkaのような専用システムの方がLISTEN/NOTIFYよりも優れたパフォーマンスを発揮します。データセンター全体での毎秒数百万メッセージの処理を目的としていません。
  • クライアント接続管理: LISTENする各クライアントは、オープンなデータベース接続を維持します。これはリソースを消費する可能性があります。スケーリングのためには、効率的な接続プーリングが不可欠です。
  • レプリケーションと高可用性: LISTEN/NOTIFYは単一のPostgreSQLインスタンス内で機能します。レプリケーション設定では、プライマリでのNOTIFYは、そこへ接続しているリスナークライアントのためにスタンバイレプリカに自動的に伝播しません。

結論

PostgreSQLのLISTEN/NOTIFYメカニズムは、PostgreSQLが既に主要なデータストアであるアプリケーションでリアルタイム機能を実装するための、驚くほど堅牢でエレガントなソリューションを提供します。この組み込み機能を利用することで、開発者は多くの一般的なユースケースで外部メッセージブローカーの複雑さとオーバーヘッドを回避し、アーキテクチャを簡素化し、運用上の負担を軽減できます。KafkaやRedis Pub/Subのような高スケールで永続的なメッセージングシステムの代替にはなりませんが、LISTEN/NOTIFYは、既存のPostgreSQLデータベースから直接リアルタイム機能を活用できる、非常に効果的で軽量な代替手段として際立っています。これにより、リアルタイムの応答性のパワーがデータが存在する場所に直接もたらされ、ダイナミックなユーザーエクスペリエンスへのよりシンプルな道筋が提供されます。

Share this article

HackerNews

More Posts from Leapcell

Popular Posts