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 버전)에서는 동일한 데이터를 두 번 (WAL은 PG 및 수동으로) 저장할 필요가 없습니다. Postgre 논리적 디코딩 메커니즘 (논리 복제와 동일)을 사용하여 데이터의 모든 또는 일부 변경 사항을 추적하거나 나중에 분석하기 위해 kafka와 같은 일부 대기열로 해당 이벤트를 보낼 수 있습니다.