วิธีต่าง ๆ ในการจับการเปลี่ยนแปลงใน Postgres

 (blog.sequin.io)
4 คะแนน โดย GN⁺ 2023-09-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บทความนี้กล่าวถึงวิธีการต่าง ๆ ในการจับการเปลี่ยนแปลงในฐานข้อมูล Postgres
  • Sequin เป็นบริษัทที่ซิงก์ข้อมูลจาก API ของบุคคลที่สาม เช่น Salesforce และ HubSpot เพื่อให้นักพัฒนาสามารถสร้างข้อมูลจาก API โดยใช้ฐานข้อมูล Postgres ของตน
  • Postgres มีตัวเลือกหลายแบบสำหรับการจับข้อมูลระหว่างการเคลื่อนย้าย เช่น การทริกเกอร์เวิร์กโฟลว์ตามการเปลี่ยนแปลงของตาราง หรือการสตรีมข้อมูลแบบเรียลไทม์ไปยังแหล่งเก็บข้อมูล ระบบ หรือบริการอื่น
  • แนวทางที่ง่ายที่สุดคือการใช้ Listen/Notify ซึ่งเป็นความสามารถด้านการสื่อสารระหว่างโปรเซสของ Postgres นี่คือการทำงานตามแพตเทิร์น publish-subscribe แต่มีข้อจำกัด เช่น semantics แบบ "อย่างมากหนึ่งครั้ง" และข้อจำกัดขนาดเพย์โหลดที่ 8000 ไบต์
  • อีกวิธีหนึ่งคือการ polling ตารางโดยตรง ซึ่งกำหนดให้แต่ละตารางต้องมีคอลัมน์ updated_at หรือสิ่งที่คล้ายกันซึ่งจะอัปเดตทุกครั้งที่มีการอัปเดตแถว อย่างไรก็ตาม วิธีนี้ไม่สามารถตรวจจับการลบแถวได้ และไม่ได้ให้ความแตกต่างของข้อมูล
  • Postgres รองรับการสตรีมรีพลิเคชันไปยังฐานข้อมูล Postgres อื่น ซึ่งสามารถใช้เพื่อจับการเปลี่ยนแปลงของแอปพลิเคชันได้ อย่างไรก็ตาม วิธีนี้ซับซ้อนและอาจต้องปรับแต่ง postgresql.conf
  • การเปลี่ยนแปลงยังสามารถจับได้จากตาราง audit ที่บันทึกการเปลี่ยนแปลง วิธีนี้คล้ายกับการใช้ replication slot แต่เป็นแบบทำด้วยมือมากกว่า
  • ยังมี foreign data wrapper (FDW) ซึ่งเป็นความสามารถของ Postgres ที่ทำให้อ่านและเขียนไปยังแหล่งข้อมูลภายนอกได้ อย่างไรก็ตาม วิธีนี้แนะนำเฉพาะในบางสถานการณ์ที่เฉพาะเจาะจงมากเท่านั้น
  • โดยสรุป วิธีที่ดีที่สุดในการจับการเปลี่ยนแปลงใน Postgres ขึ้นอยู่กับกรณีการใช้งาน Listen/Notify เหมาะกับการจับเหตุการณ์ที่ไม่สำคัญมาก การ polling การเปลี่ยนแปลงเป็นวิธีแก้ที่ตรงไปตรงมาสำหรับกรณีใช้งานง่าย ๆ และการรีพลิเคชันคือทางเลือกที่ดีที่สุดสำหรับโซลูชันที่แข็งแรง หากการรีพลิเคชันยากเกินไป ตาราง audit อาจเป็นทางออกกึ่งกลางที่ดีได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-24
ความคิดเห็นจาก Hacker News
  • บทความนี้กล่าวถึงวิธีต่าง ๆ ในการจับการเปลี่ยนแปลงใน Postgres ซึ่งเป็นระบบฐานข้อมูลยอดนิยม
  • ผู้แสดงความคิดเห็นคนหนึ่งแนะนำอย่างยิ่งให้ใช้ trigger และตารางประวัติ (audit table) ซึ่งเป็นเทคนิคที่ใช้งานกันมานานกว่า 30 ปีในการจับการเปลี่ยนแปลง
  • ผู้แสดงความคิดเห็นได้ให้ลิงก์คู่มือเกี่ยวกับวิธีนำเทคนิคนี้ไปใช้ และเตือนเกี่ยวกับการใช้ไลบรารีติดตามประวัติในฝั่งแอปพลิเคชัน
  • ผู้แสดงความคิดเห็นอีกรายแบ่งปันประสบการณ์เชิงบวกเกี่ยวกับรูปแบบ Temporal Tables ซึ่งช่วยให้ดูสถานะของตาราง ณ ช่วงเวลาที่กำหนดได้
  • ผู้แสดงความคิดเห็นอีกรายเสนอให้ใช้ส่วนขยายที่ผ่านการพิสูจน์แล้วสำหรับสร้างตารางตรวจสอบชื่อว่า pgaudit
  • ผู้แสดงความคิดเห็นบางคนพูดถึงความเสี่ยงที่อาจเกิดขึ้นของบางวิธี เช่น การ polling คอลัมน์ updated_time
  • มีการกล่าวถึงไลบรารีสำหรับผู้ใช้ Elixir และ Postgres ที่ใช้ฟังการเปลี่ยนแปลงของ WAL
  • ผู้แสดงความคิดเห็นบางคนแสดงความเห็นว่าพื้นที่นี้ยังต้องการนวัตกรรม และเสนอว่า Postgres น่าจะได้ประโยชน์จากความสามารถในการ push ผลลัพธ์ของ query แบบ incremental
  • ผู้แสดงความคิดเห็นคนหนึ่งเตือนถึงความเสี่ยงของการใช้ replication เพื่อจับการเปลี่ยนแปลง โดยบอกว่าเมื่อ Postgres หยุดรับการ consume ข้อมูล มันอาจเก็บข้อมูลที่พลาดไว้จนดิสก์เต็ม
  • ผู้แสดงความคิดเห็นคนเดิมบอกว่าเขาใช้ polling แต่แนะนำให้เก็บ txid แทน updated_at
  • การสนทนานี้เน้นให้เห็นส่วนหนึ่งของโลกข้อมูล นั่นคือความจำเป็นของวิธีแก้ปัญหาที่เรียบง่ายสำหรับการ push ผลลัพธ์ของ query แบบ incremental