4 điểm bởi GN⁺ 2023-09-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bài viết bàn về nhiều cách khác nhau để ghi nhận thay đổi trong cơ sở dữ liệu Postgres.
  • Một công ty tên là Sequin đồng bộ dữ liệu từ các API bên thứ ba như Salesforce và HubSpot để giúp các nhà phát triển xây dựng trên dữ liệu API bằng chính cơ sở dữ liệu Postgres của họ.
  • Postgres cung cấp nhiều lựa chọn để ghi nhận dữ liệu đang thay đổi, chẳng hạn kích hoạt workflow dựa trên thay đổi của bảng hoặc stream dữ liệu sang kho dữ liệu, hệ thống hay dịch vụ khác theo thời gian thực.
  • Cách tiếp cận đơn giản nhất là dùng Listen/Notify, tính năng giao tiếp liên tiến trình của Postgres. Đây là một triển khai của mẫu publish-subscribe, nhưng có các giới hạn như ngữ nghĩa phân phối "nhiều nhất một lần" và giới hạn kích thước payload 8000 byte.
  • Một cách khác là polling trực tiếp bảng, yêu cầu mỗi bảng phải có cột updated_at hoặc tương tự được cập nhật mỗi khi một hàng thay đổi. Tuy nhiên, cách này không thể phát hiện khi hàng bị xóa và cũng không cung cấp phần chênh lệch.
  • Postgres hỗ trợ streaming replication sang cơ sở dữ liệu Postgres khác, và có thể dùng để ghi nhận thay đổi của ứng dụng. Tuy nhiên, cách này phức tạp và có thể cần điều chỉnh postgresql.conf.
  • Thay đổi cũng có thể được ghi nhận từ các bảng audit dùng để log các thay đổi. Cách tiếp cận này tương tự việc dùng replication slot, nhưng mang tính thủ công hơn.
  • Ngoài ra còn có foreign data wrapper (FDW), tính năng của Postgres cho phép đọc và ghi với các nguồn dữ liệu bên ngoài. Tuy nhiên, cách này chỉ được khuyến nghị trong những tình huống rất cụ thể.
  • Kết lại, cách tốt nhất để ghi nhận thay đổi trong Postgres phụ thuộc vào từng trường hợp sử dụng. Listen/Notify phù hợp để bắt các sự kiện không quá quan trọng, polling thay đổi là giải pháp trực quan cho các trường hợp đơn giản, còn replication là lựa chọn tốt nhất cho một giải pháp vững chắc. Nếu replication quá khó, bảng audit có thể là một giải pháp trung gian tốt.

1 bình luận

 
GN⁺ 2023-09-24
Ý kiến Hacker News
  • Bài viết thảo luận về nhiều cách khác nhau để ghi nhận thay đổi trong Postgres, một hệ quản trị cơ sở dữ liệu phổ biến.
  • Một người bình luận đặc biệt khuyến nghị mạnh mẽ việc dùng trigger và bảng lịch sử (bảng audit) để ghi nhận thay đổi, một kỹ thuật đã được sử dụng hơn 30 năm.
  • Người bình luận cung cấp liên kết tới hướng dẫn về cách triển khai kỹ thuật này, đồng thời cảnh báo về việc sử dụng thư viện theo dõi lịch sử ở tầng ứng dụng.
  • Một người bình luận khác chia sẻ trải nghiệm tích cực với mẫu Temporal Tables, cho phép xem trạng thái của bảng tại một thời điểm cụ thể.
  • Một người khác đề xuất sử dụng tiện ích mở rộng đã được kiểm chứng có tên pgaudit, vốn tạo ra các bảng audit.
  • Một số người bình luận thảo luận về những rủi ro tiềm ẩn của các phương pháp cụ thể, chẳng hạn như polling cột updated_at.
  • Cũng có đề cập đến một thư viện lắng nghe thay đổi WAL dành cho người dùng Elixir & Postgres.
  • Một vài người bình luận cho rằng lĩnh vực này cần đổi mới, và gợi ý rằng Postgres sẽ được hưởng lợi từ khả năng đẩy dần kết quả truy vấn.
  • Một người bình luận cảnh báo về rủi ro khi dùng replication để ghi nhận thay đổi, nói rằng nếu Postgres ngừng tiêu thụ dữ liệu thì dữ liệu bị bỏ lỡ có thể tiếp tục được lưu cho đến khi đầy đĩa.
  • Cũng người bình luận đó cho biết họ dùng polling nhưng lưu txid thay vì updated_at.
  • Cuộc thảo luận nhấn mạnh một khía cạnh của thế giới dữ liệu: cần có một giải pháp gọn gàng để đẩy dần kết quả truy vấn.