Масштабування PostgreSQL TRIGGER (s)

Як Postgres запускає механізм масштабу?

У нас є велика установка PostgreSQL, і ми намагаємось реалізувати систему на основі подій, використовуючи таблиці журналів та TRIGGER (s).

В основному ми хотіли б створити TRIGGER для кожної таблиці, про яку ми хочемо отримувати сповіщення про операцію UPDATE / INSERT / DELETE. Після запуску цього тригера він виконає функцію, яка просто додасть нову рядок (кодування події) до таблиці журналів, яку ми потім опитуємо від зовнішньої служби.

Перш ніж розпочати роботу з Postgres TRIGGER, ми хотіли б дізнатися, як вони масштабують: скільки тригерів ми можемо створити в одній установці Postgres? Чи впливають вони на ефективність запитів? Хтось раніше пробував це?

В основному ми хотіли б створити TRIGGER для кожної таблиці, про яку ми хочемо отримувати сповіщення про операцію UPDATE / INSERT / DELETE. Після запуску цього тригера він виконає функцію, яка просто додасть нову рядок (кодування події) до таблиці журналів, яку ми потім опитуємо від зовнішньої служби.

Це досить стандартне використання тригера.

Перш ніж розпочати роботу з Postgres TRIGGER, ми хотіли б дізнатися, як вони масштабують: скільки тригерів ми можемо створити в одній установці Postgres?

Якщо ви продовжуєте їх створювати, врешті-решт не вистачить місця на диску.

Немає конкретного обмеження для тригерів.

Ліміти PostgreSQL задокументовані на сторінці about .

Чи впливають вони на ефективність запитів?

Це залежить від типу тригера, мови тригера та того, що робить тригер.

Простий BEFORE ... FOR EACH STATEMENTтригер PL / PgSQL, який нічого не робить, має майже нульові накладні витрати.

FOR EACH ROWтригери мають вищі накладні витрати, ніж FOR EACH STATEMENTтригери. Масштабування, очевидно, враховує порушений ряд.

AFTERтригери коштують дорожче, ніж BEFOREтригери, тому що їх потрібно ставити в чергу, поки оператор не закінчить виконувати свою роботу, а потім виконати. Вони не перекидаються на диск, якщо черга стає великою (принаймні в 9,4 і нижче, можливо, зміниться в майбутньому), тому величезні AFTERтригерні черги можуть спричинити перевищення наявної пам'яті, в результаті чого оператор скасовує.

Тригер, який змінює NEWрядок перед вставкою / оновленням, дешевший, ніж тригер, який робить DML.

Конкретний випадок використання, який ви хочете, матиме кращу ефективність із вдосконаленням у процесі роботи, яке може перетворити його на PostgreSQL 9.5 (якщо нам пощастить), де FOR EACH STATEMENTтригери можуть бачити віртуальний OLDта NEWтаблиці. У поточних версіях PostgreSQL це неможливо, тому вам потрібно використовувати FOR EACH ROWтригери.

Хтось раніше пробував це?

Звичайно. Це досить стандартне використання тригерів, а також аудит, перевірка рівня безпеки та ін.

Ви захочете розглянути LISTENі NOTIFYяк добре розбудити свого працівника, коли відбудуться зміни в таблиці завдань.

Ви вже робите найважливіше, уникаючи спілкування із зовнішніми системами безпосередньо з пускових механізмів. Це, як правило, є проблематичним для продуктивності та надійності. Люди часто намагаються робити такі речі, як надсилання пошти безпосередньо з тригера, і це погана новина.

Це трохи запізніла відповідь, але може бути корисною для майбутніх читачів

Зараз днів (у 10,11,12 версіях) нам не потрібно зберігати однакові дані двічі (у WAL по PG та вручну). Ми можемо використовувати механіку Postgre Logical Decoding (подібно до логічної реплікації) для відстеження всіх або деяких змін наших даних (або надсилати ці події до якоїсь черги, наприклад, kafka для подальшого аналізу)