LISTEN და NOTIFY უზრუნველყოფენ ჩაშენებულ publish/subscribe მესიჯინგ სისტემას PostgreSQL-ში — ერთი სესია შეიძლება გამოაცხადოს ნოტიფიკაცია არხზე, და სხვა სესიები, რომლებიც ამ არხზე ყურადღებას აქცევენ, მას დაუყოვნებლივ მიიღებენ. ეს არის მსუბუქი გზა რეალურ დროში ღონისძიებების ბაზიდან გამოსაგზავნად დამკითხვის გარეშე.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN ხელმოწერს არხზე; NOTIFY აქვეყნებს მას (არჩევითი ტექსტური დატვირთვით). ყურადღება მიმართავები იღებენ ნოტიფიკაციას ასინქრონულად — დამკითხვა არ არის საჭირო.
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
PERFORM pg_notify('order_created', NEW.id::text); -- notify with the new id
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER order_notify AFTER INSERT ON orders
FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
NOTIFY-ის ტრიგერთან გაერთიანება საშუალებას აძლევს ბაზას ავტომატურად გამოუშვას ღონისძიებები მონაცემების ცვლილებისას (ახალი შეკვეთა, სტატუსის განახლება) — აპლიკაციის სერვერები, რომლებიც ამ არხზე ყურადღებას აქცევენ, რეალურ დროში რეაგირებენ.
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
(no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
proper broker (RabbitMQ, Kafka) or a queue table.
LISTEN/NOTIFY არის სასარგებლო, გარკვევით ნაკლებად ცნობილი PostgreSQL ფიჩა, რომელიც უზრუნველყოფს ჩაშენებულ pub/sub მესიჯინგს, ღირებული აპლიკაციებში რეალურ დროში რეაქტიულობის დასამატებლად დამკითხვის გარეშე.
ძირითადი მნიშვნელობა ის არის, რომ ბაზა შეძლოს ღონისძიებების გამოგზავნა ყურადღება მიმართავ აპლიკაციის სესიებზე დაუყოვნებლივ, როდესაც რაიმე ხდება (ახალი შეკვეთა, სტატუსის ცვლილება) — ჩვეულებრივ გაერთიანებული ტრიგერებთან, ასე რომ მონაცემების ცვლილებები ავტომატურად აცნობებენ ყურადღება მიმართავებს, რომელთა აპლიკაციის სერვერები რეაგირებენ (websockets-ში გამოგზავნა, კეშის გაუქმება, ფონურ სამუშაოს გამოწვევა).
ეს ღირებულია, რადგან უზრუნველყოფს რეალურ დროში ღონისძიებებით მართულ ქცევას ბაზის განმეორებითი დამკითხვის inefficiency-ის გარეშე (გავრცელებული, საფუჭვე ნიმუში, რომელიც LISTEN/NOTIFY ელეგანტურად ცვლის).
მექანიზმის გაგება (LISTEN აბონენტობისთვის, NOTIFY გამოქვეყნებისთვის, ტრიგერებთან მონაცემების ცვლილებების დროს ავტომატური ნოტიფიკაციისთვის) და მისი გამოყენება აპლიკაციებში (ღონისძიებებთან ამთავრობა რეალურ დროში რეაქციების მოწვევისთვის) სასარგებლოა რეაქტიული, ღონისძიებებით მართული აპლიკაციების აგებისთვის მხოლოდ PostgreSQL-ის გამოყენებით.
თანაბრად მნიშვნელოვანი არის შეზღუდვების ცოდნა: ნოტიფიკაციები არ არის დაცული (დაკარგული, თუ არავის აქვს ამ ის მოსმენა — მტკიცეობის გარანტიები არ არსებობს), მცირე დატვირთვაა, და ხელმოწერის შემდეგ ამუშრავდება — ამიტომ ის შეესაბამება მსუბუქ რეალურ დროში სიგნალს, არა ხელმოწერილი მესიჯ ბროკერის ჩანაცვლება (RabbitMQ, Kafka) როდესაც საიმედოობა და სიდიდეშ მნიშვნელოვანია.
მას შემდეგ, რაც რეალურ დროში რეაქტიულობა ხშირი საჭიროებაა და LISTEN/NOTIFY იძლევა ჩაშენებულ, დამკითხვის გარეშე გზას მისი მოთხოვნისთვის მსუბუქი შემთხვევებში, მის გაგება — pub/sub მექანიზმი, ტრიგერი ნიმუში, და მნიშვნელოვნად მისი შეზღუდვები (როდის საკმარისია ის ბუ როდის დასჭირდება რეალური ბროკერი) — ღირებული, პრაქტიკულად შესაბამისი PostgreSQL ცოდნა ღონისძიებებით მართული აპლიკაციების აგებისთვის, სასარგებლო ჩაშენებული ფიჩა, რომელიც ხშირად უცდებიან.