มาตราส่วน PostgreSQL TRIGGER

Postgres กระตุ้นกลไกการปรับขนาดอย่างไร

เรามีการติดตั้ง PostgreSQL ขนาดใหญ่และเราพยายามที่จะใช้ระบบที่อิงเหตุการณ์โดยใช้ตารางบันทึกและ TRIGGER

โดยทั่วไปเราต้องการสร้าง TRIGGER สำหรับแต่ละตารางที่เราต้องการรับการแจ้งเตือนสำหรับการดำเนินการ UPDATE / INSERT / DELETE เมื่อทริกเกอร์นี้เริ่มทำงานมันจะเรียกใช้ฟังก์ชั่นที่จะเพิ่มแถวใหม่ (เข้ารหัสเหตุการณ์) ลงในตารางบันทึกที่เราจะสำรวจจากบริการภายนอก

ก่อนที่จะเข้าร่วมกับ Postgres TRIGGER (s) เราต้องการทราบวิธีการปรับขนาด: เราสามารถสร้างทริกเกอร์จำนวนเท่าใดในการติดตั้ง Postgres เดียว ส่งผลกระทบต่อประสิทธิภาพการค้นหาหรือไม่ ใครเคยลองสิ่งนี้บ้างไหม?

โดยทั่วไปเราต้องการสร้าง TRIGGER สำหรับแต่ละตารางที่เราต้องการรับการแจ้งเตือนสำหรับการดำเนินการ UPDATE / INSERT / DELETE เมื่อทริกเกอร์นี้เริ่มทำงานมันจะเรียกใช้ฟังก์ชั่นที่จะเพิ่มแถวใหม่ (เข้ารหัสเหตุการณ์) ลงในตารางบันทึกที่เราจะสำรวจจากบริการภายนอก

นั่นเป็นการใช้งานทริกเกอร์

ก่อนที่จะเข้าร่วมกับ Postgres TRIGGER (s) เราต้องการทราบวิธีการปรับขนาด: เราสามารถสร้างทริกเกอร์จำนวนเท่าใดในการติดตั้ง Postgres เดียว

หากคุณสร้างมันขึ้นมาในที่สุดคุณก็จะมีพื้นที่ดิสก์เหลืออยู่

ไม่มีข้อ จำกัด สำหรับทริกเกอร์

ข้อ จำกัด PostgreSQL ได้รับการบันทึกในหน้าเกี่ยวกับ

ส่งผลกระทบต่อประสิทธิภาพการค้นหาหรือไม่

ขึ้นอยู่กับประเภทของทริกเกอร์ภาษาของทริกเกอร์และสิ่งที่ทริกเกอร์ทำ

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 (เหมือนกับการจำลองแบบลอจิคัล) เพื่อติดตามการเปลี่ยนแปลงทั้งหมดหรือบางส่วนของข้อมูลของเรา (หรือส่งเหตุการณ์เหล่านั้นไปยังคิวบางอย่างเช่น kafka เพื่อวิเคราะห์ในภายหลัง)