4P by neo 8달전 | favorite | 댓글 1개
  • 기사는 Postgres 데이터베이스의 변화를 포착하는 다양한 방법에 대해 논의합니다.
  • Sequin이라는 회사는 Salesforce와 HubSpot과 같은 제3자 API로부터 데이터를 동기화하여 개발자들이 그들의 Postgres 데이터베이스를 사용하여 API 데이터를 구축하게 합니다.
  • Postgres는 테이블 변화에 기반한 워크플로우를 트리거하거나, 실시간으로 다른 데이터 저장소, 시스템, 또는 서비스로 데이터를 스트리밍하는 등, 이동 중인 데이터를 포착하는 여러 옵션을 제공합니다.
  • 가장 간단한 접근법은 Postgres의 프로세스 간 통신 기능인 Listen/Notify를 사용하는 것입니다. 이는 publish-subscribe 패턴의 구현체이지만, "최대 한 번" 배달 의미론과 8000 바이트의 페이로드 크기 제한과 같은 제한이 있습니다.
  • 또 다른 방법은 테이블을 직접 폴링하는 것으로, 이는 각 테이블이 행이 업데이트될 때마다 업데이트되는 updated_at 칼럼이나 유사한 것을 가지고 있어야 합니다. 그러나 이 방법은 행이 삭제될 때를 감지할 수 없으며, 차이를 제공하지 않습니다.
  • Postgres는 다른 Postgres 데이터베이스로의 스트리밍 복제를 지원하며, 이는 애플리케이션의 변화를 포착하는 데 사용될 수 있습니다. 그러나 이 방법은 복잡하며 postgresql.conf를 조정해야 할 수도 있습니다.
  • 변화는 또한 변경 사항을 로깅하는 감사 테이블에서 포착될 수 있습니다. 이 접근법은 복제 슬롯을 사용하는 것과 유사하지만, 더 수동적입니다.
  • 외부 데이터 소스에서 읽고 쓸 수 있게 해주는 Postgres 기능인 외부 데이터 래퍼(FDWs)도 있습니다. 그러나 이 방법은 매우 특정한 상황에서만 권장됩니다.
  • 결론적으로, Postgres에서 변화를 포착하는 최선의 방법은 사용 사례에 따라 달라집니다. Listen/Notify는 비중요 이벤트 포착에 좋고, 변화를 폴링하는 것은 간단한 사용 사례에 대한 직관적인 해결책이며, 복제는 견고한 해결책에 대한 최선의 선택입니다. 복제가 너무 어렵다면, 감사 테이블이 좋은 중간 해결책이 될 수 있습니다.
Hacker News 의견
  • 기사는 인기 있는 데이터베이스 시스템인 Postgres에서 변화를 포착하는 다양한 방법을 논의합니다.
  • 한 댓글러는 30년 넘게 사용되어 온 기법인 트리거와 이력 테이블(감사 테이블)을 사용하여 변화를 포착하는 것을 강력히 권장합니다.
  • 댓글러는 이 기법을 구현하는 방법에 대한 가이드 링크를 제공하며, 애플리케이션 공간 이력 추적 라이브러리를 사용하는 것에 대해 경고합니다.
  • 다른 댓글러는 특정 시점의 테이블 상태를 볼 수 있게 해주는 Temporal Tables 패턴에 대한 긍정적인 경험을 공유합니다.
  • 다른 댓글러는 "pgaudit"라는 감사 테이블을 생성하는 검증된 확장 기능을 사용하는 것을 제안합니다.
  • 일부 댓글러들은 업데이트된_시간 열을 폴링하는 것과 같은 특정 방법의 잠재적 위험성을 논의합니다.
  • Elixir & Postgres 사용자를 위한 WAL 변화를 듣는 라이브러리에 대한 언급이 있습니다.
  • 몇몇 댓글러들은 이 분야에서 혁신이 필요하다고 표현하며, Postgres가 쿼리 결과를 점진적으로 푸시하는 기능에서 이익을 볼 수 있을 것이라고 제안합니다.
  • 한 댓글러는 복제를 사용하여 변화를 포착하는 것의 위험성에 대해 경고하며, Postgres가 데이터를 소비하는 것을 중단하면 놓친 데이터를 디스크가 가득 찰 때까지 저장할 수 있다고 말합니다.
  • 같은 댓글러는 폴링을 사용하지만 updated_at 대신 txid를 저장하는 것을 제안합니다.
  • 논의에서는 데이터 세계의 한 부분을 강조하고 있습니다 - 쿼리 결과를 점진적으로 푸시하는 깔끔한 해결책이 필요하다는 것입니다.