การแปลบทความจัดทำขึ้นเฉพาะสำหรับนักศึกษาของหลักสูตร
การตั้งค่าความสอดคล้องในการเขียน PostgreSQL และการเชื่อมต่อเฉพาะ
ที่ Compose เราต้องจัดการกับฐานข้อมูลจำนวนมาก ซึ่งเปิดโอกาสให้เราได้รู้จักฟังก์ชันการทำงานและข้อบกพร่องของฐานข้อมูลเหล่านี้มากขึ้น เมื่อเราเรียนรู้ที่จะรักฟีเจอร์ของฐานข้อมูลใหม่ บางครั้งเราก็เริ่มคิดว่าจะดีแค่ไหนหากฟีเจอร์ที่คล้ายกันนี้ปรากฏในเครื่องมือที่เป็นผู้ใหญ่มากกว่าที่เราร่วมงานด้วยมาเป็นเวลานาน หนึ่งในคุณสมบัติใหม่ที่ฉันต้องการเห็นใน PostgreSQL คือความสอดคล้องในการเขียนที่กำหนดค่าได้ต่อการเชื่อมต่อทั่วทั้งคลัสเตอร์ และปรากฎว่า เรามีมันแล้ว และวันนี้เราต้องการแบ่งปันข้อมูลเกี่ยวกับวิธีการใช้งานของคุณ
ทำไมฉันถึงต้องการมัน?
คลัสเตอร์ควรทำงานอย่างไรนั้นขึ้นอยู่กับแอปพลิเคชันของคุณ ยกตัวอย่างแอปจ่ายบิล คุณจะต้องมีความสอดคล้องกัน XNUMX% ทั่วทั้งคลัสเตอร์ ดังนั้นคุณจะต้องเปิดใช้งานการคอมมิตแบบซิงโครนัสเพื่อให้ฐานข้อมูลของคุณรอการเปลี่ยนแปลงทั้งหมด อย่างไรก็ตาม หากแอปพลิเคชันของคุณเป็นเครือข่ายโซเชียลที่เติบโตอย่างรวดเร็ว คุณอาจต้องการการตอบสนองที่รวดเร็วมากกว่าความสม่ำเสมอ XNUMX% เพื่อให้บรรลุเป้าหมายนี้ คุณสามารถใช้การคอมมิตแบบอะซิงโครนัสในคลัสเตอร์ของคุณได้
พบกับการประนีประนอม
คุณต้องทำการแลกเปลี่ยนระหว่างความสอดคล้องของข้อมูลและประสิทธิภาพ PostgreSQL เลิกใช้ความสอดคล้องกันเนื่องจากการกำหนดค่าเริ่มต้นนั้นสามารถคาดเดาได้และไม่มีเหตุไม่คาดคิด ตอนนี้เรามาดูการประนีประนอมกัน
ข้อดีข้อที่ 1: ประสิทธิภาพ
หากคลัสเตอร์ PostgreSQL ไม่ต้องการความสอดคล้อง คลัสเตอร์ก็สามารถทำงานแบบอะซิงโครนัสได้ การเขียนเกิดขึ้นกับผู้นำคลัสเตอร์ และการอัปเดตจะถูกส่งไปยังเรพลิกาภายในไม่กี่มิลลิวินาทีต่อมา เมื่อคลัสเตอร์ PostgreSQL ต้องการความสอดคล้อง คลัสเตอร์นั้นจะต้องทำงานพร้อมกัน การเขียนจะถูกส่งไปยังผู้นำคลัสเตอร์ ซึ่งจะส่งการอัปเดตไปยังเรพลิกาและรอการยืนยันว่าแต่ละรายการเขียนแล้ว ก่อนที่จะส่งการยืนยันไปยังไคลเอนต์ที่เริ่มการเขียนว่าสำเร็จแล้ว ข้อแตกต่างในทางปฏิบัติระหว่างแนวทางเหล่านี้คือ วิธีอะซิงโครนัสต้องใช้การกระโดดเครือข่ายสองครั้ง ในขณะที่วิธีการซิงโครนัสต้องใช้สี่ครั้ง
ข้อดีข้อที่ 2: ความสม่ำเสมอ
ผลลัพธ์ในกรณีที่ผู้นำล้มเหลวในสองแนวทางนี้จะแตกต่างกันเช่นกัน หากงานดำเนินการแบบอะซิงโครนัส หากเกิดข้อผิดพลาดดังกล่าว เรพลิกาอาจไม่ใช่บันทึกทั้งหมดที่จะคอมมิต จะขาดทุนขนาดไหน? ขึ้นอยู่กับแอปพลิเคชันและประสิทธิภาพของการจำลอง การจำลองแบบการเขียนจะป้องกันไม่ให้แบบจำลองกลายเป็นผู้นำหากปริมาณข้อมูลในนั้นน้อยกว่าผู้นำ 1 MB นั่นคือ เร็กคอร์ดสูงสุด 1 MB อาจสูญหายระหว่างการดำเนินการแบบอะซิงโครนัส
สิ่งนี้ไม่ได้เกิดขึ้นในโหมดซิงโครนัส หากผู้นำล้มเหลว เรพลิกาทั้งหมดจะถูกอัพเดต เนื่องจากการเขียนใดๆ ที่ยืนยันเกี่ยวกับผู้นำจะต้องได้รับการยืนยันบนเรพลิกา นี่คือความสม่ำเสมอ
พฤติกรรมแบบซิงโครนัสเหมาะสมในแอปพลิเคชันการเรียกเก็บเงินซึ่งความสอดคล้องมีข้อได้เปรียบที่ชัดเจนในการแลกเปลี่ยนระหว่างความสม่ำเสมอและประสิทธิภาพ สิ่งที่สำคัญที่สุดสำหรับแอปพลิเคชันดังกล่าวคือข้อมูลที่ถูกต้อง ตอนนี้ให้คิดถึงเครือข่ายโซเชียลที่ภารกิจหลักคือการดึงดูดความสนใจของผู้ใช้ด้วยการตอบกลับคำขอโดยเร็วที่สุด ในกรณีนี้ ประสิทธิภาพที่มีการกระโดดข้ามเครือข่ายน้อยลงและรอการคอมมิตน้อยลงจะมีความสำคัญเป็นอันดับแรก อย่างไรก็ตาม ข้อเสียระหว่างประสิทธิภาพและความสม่ำเสมอไม่ใช่สิ่งเดียวที่คุณต้องคำนึงถึง
การแลกเปลี่ยน 3: การขัดข้อง
สิ่งสำคัญมากคือต้องเข้าใจว่าคลัสเตอร์ทำงานอย่างไรในระหว่างเกิดความล้มเหลว พิจารณาสถานการณ์ที่แบบจำลองหนึ่งรายการขึ้นไปล้มเหลว เมื่อคอมมิตถูกประมวลผลแบบอะซิงโครนัส ผู้นำจะยังคงทำงานต่อไป กล่าวคือ ยอมรับและประมวลผลการเขียน โดยไม่ต้องรอเรพลิกาที่หายไป เมื่อแบบจำลองกลับสู่คลัสเตอร์ แบบจำลองจะตามทันผู้นำ ด้วยการจำลองแบบซิงโครนัส หากเรพลิกาไม่ตอบสนอง ผู้นำจะไม่มีทางเลือกและจะรอการยืนยันคอมมิตต่อไปจนกว่าเรพลิกาจะกลับไปที่คลัสเตอร์และสามารถยอมรับและคอมมิตการเขียนได้
หนึ่งการเชื่อมต่อต่อธุรกรรม?
ทุกแอปพลิเคชันต้องการการผสมผสานระหว่างความสม่ำเสมอและประสิทธิภาพที่แตกต่างกัน เว้นแต่จะเป็นแอปจ่ายบิลของเรา ซึ่งเราจินตนาการว่ามีความสอดคล้องกันโดยสิ้นเชิง หรือแอปโซเชียลเน็ตเวิร์กที่เกือบจะเกิดขึ้นชั่วคราว ในกรณีอื่นๆ ทั้งหมด จะมีบางครั้งที่การดำเนินการบางอย่างต้องเป็นแบบซิงโครนัส และบางอย่างต้องเป็นแบบอะซิงโครนัส คุณอาจไม่ต้องการให้ระบบรอจนกว่าข้อความที่ส่งไปยังแชทจะเกิดขึ้น แต่หากการชำระเงินได้รับการประมวลผลในแอปพลิเคชันเดียวกันคุณจะต้องรอ
แน่นอนว่าการตัดสินใจทั้งหมดนี้ทำโดยนักพัฒนาแอปพลิเคชัน การตัดสินใจที่ถูกต้องว่าควรใช้แต่ละแนวทางเมื่อใดจะช่วยให้คุณได้รับประโยชน์สูงสุดจากคลัสเตอร์ของคุณ เป็นสิ่งสำคัญที่นักพัฒนาสามารถสลับระหว่างพวกเขาในระดับ SQL สำหรับการเชื่อมต่อและการทำธุรกรรม
มั่นใจในการควบคุมในทางปฏิบัติ
ตามค่าเริ่มต้น PostgreSQL จะให้ความสอดคล้องกัน สิ่งนี้ถูกควบคุมโดยพารามิเตอร์เซิร์ฟเวอร์ synchronous_commit
. โดยค่าเริ่มต้นจะอยู่ในตำแหน่ง on
แต่มีอีกสามตัวเลือก: local
, remote_write
หรือ off
.
เมื่อตั้งค่าพารามิเตอร์เป็น off
การคอมมิตแบบซิงโครนัสทั้งหมดจะหยุดลง แม้แต่บนระบบโลคัลก็ตาม พารามิเตอร์โลคัลระบุโหมดซิงโครนัสสำหรับระบบโลคัล แต่การเขียนไปยังเรพลิกาจะดำเนินการแบบอะซิงโครนัส Remote_write
ยิ่งไปกว่านั้น: การเขียนไปยังเรพลิกาจะทำแบบอะซิงโครนัส แต่จะถูกส่งคืนเมื่อเรพลิกายอมรับการเขียน แต่ยังไม่ได้เขียนลงดิสก์
เมื่อพิจารณาตัวเลือกที่มีอยู่ เราจะเลือกพฤติกรรมและคำนึงไว้เสมอ on
– นี่คือการบันทึกแบบซิงโครนัส เราจะเลือก local
สำหรับการคอมมิตแบบอะซิงโครนัสบนเครือข่าย ในขณะที่ปล่อยให้คอมมิตแบบซิงโครนัสภายในเครื่อง
ตอนนี้ เราจะบอกคุณถึงวิธีการตั้งค่านี้ในอีกสักครู่ แต่ลองจินตนาการว่าเราตั้งค่าแล้ว synchronous_commit
в local
สำหรับเซิร์ฟเวอร์ เราสงสัยว่าเป็นไปได้หรือไม่ที่จะเปลี่ยนพารามิเตอร์ synchronous_commit
ทันทีและปรากฎว่าไม่เพียงเป็นไปได้เท่านั้น ยังมีสองวิธีในการทำเช่นนี้ ประการแรกคือการตั้งค่าเซสชันของการเชื่อมต่อของคุณดังนี้:
SET SESSION synchronous_commit TO ON;
// Your writes go here
การเขียนที่ตามมาทั้งหมดในเซสชันจะรับทราบการเขียนไปยังแบบจำลองก่อนที่จะส่งคืนผลลัพธ์เชิงบวกไปยังไคลเอนต์ที่เชื่อมต่อ เว้นแต่คุณจะเปลี่ยนการตั้งค่า synchronous_commit
อีกครั้ง. คุณสามารถละเว้นบางส่วนได้ SESSION
ในคำสั่งเพราะจะเป็นค่าเริ่มต้น
วิธีที่สองนั้นดีเมื่อคุณต้องการให้แน่ใจว่าคุณได้รับการจำลองแบบซิงโครนัสสำหรับธุรกรรมเดียว ในฐานข้อมูลการสร้าง NoSQL จำนวนมาก แนวคิดของธุรกรรมไม่มีอยู่จริง แต่มีอยู่ใน PostgreSQL ในกรณีนี้คุณเริ่มธุรกรรมแล้วตั้งค่า synchronous_commit
в on
ก่อนที่จะดำเนินการรายการสำหรับการทำธุรกรรม COMMIT
จะกระทำธุรกรรมโดยใช้ค่าพารามิเตอร์ใด ๆ synchronous_commit
ซึ่งตั้งค่าไว้ในขณะนั้น แม้ว่าจะเป็นการดีที่สุดที่จะตั้งค่าตัวแปรล่วงหน้าเพื่อให้แน่ใจว่านักพัฒนารายอื่นเข้าใจว่าการเขียนนั้นไม่อะซิงโครนัส
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT;
การทำธุรกรรมทั้งหมดจะได้รับการยืนยันว่าเขียนลงในแบบจำลองก่อนที่ฐานข้อมูลจะตอบกลับเชิงบวกไปยังไคลเอนต์ที่เชื่อมต่อ
การกำหนดค่า PostgreSQL
ก่อนหน้านี้เราจินตนาการถึงระบบ PostgreSQL ด้วย synchronous_commit
, ติดตั้งใน local
. เพื่อให้สิ่งนี้เป็นจริงบนฝั่งเซิร์ฟเวอร์ คุณจะต้องตั้งค่าตัวเลือกการกำหนดค่าเซิร์ฟเวอร์สองตัว อีกหนึ่งพารามิเตอร์ synchronous_standby_names
จะมาเองเมื่อไร. synchronous_commit
จะอยู่ใน on
. จะกำหนดว่าเรพลิกาใดมีสิทธิ์รับการคอมมิตแบบซิงโครนัส และเราจะตั้งค่าให้ *
ซึ่งหมายความว่ามีการจำลองทั้งหมดเกี่ยวข้อง โดยปกติแล้วค่าเหล่านี้จะถูกกำหนดค่าไว้
synchronous_commit = local
synchronous_standby_names='*'
โดยการตั้งค่าพารามิเตอร์ synchronous_commit
สู่ความหมาย local
เราสร้างระบบที่ดิสก์ในเครื่องยังคงซิงโครนัส แต่การจำลองเครือข่ายที่คอมมิตเป็นแบบอะซิงโครนัสตามค่าเริ่มต้น เว้นแต่ว่าเราตัดสินใจที่จะทำให้คอมมิตเหล่านี้ซิงโครนัสดังที่แสดงไว้ข้างต้น
หากคุณได้ติดตามพัฒนาการ
อีกไม่กี่คำ...
เมื่อสัปดาห์ที่แล้ว ฉันคงบอกคุณไปแล้วว่าการปรับแต่ง PostgreSQL อย่างประณีตนั้นเป็นไปไม่ได้ นั่นคือตอนที่ Kurt สมาชิกของทีมแพลตฟอร์ม Compose ยืนกรานว่ามีโอกาสเช่นนี้อยู่ เขาทำให้การคัดค้านของฉันสงบลงและพบในเอกสารของ PostgreSQL
การตั้งค่านี้สามารถเปลี่ยนแปลงได้ตลอดเวลา ลักษณะการทำงานของธุรกรรมใดๆ จะถูกกำหนดโดยการตั้งค่าที่มีผล ณ เวลาที่กระทำการ ดังนั้นจึงเป็นไปได้และมีประโยชน์สำหรับบางธุรกรรมที่จะกระทำแบบซิงโครนัสและสำหรับธุรกรรมอื่นแบบอะซิงโครนัส เช่น การบังคับอย่างหนึ่ง multistatement
ธุรกรรมที่จะกระทำแบบอะซิงโครนัสเมื่อค่าเริ่มต้นของพารามิเตอร์อยู่ตรงข้าม ให้ตั้งค่า SET LOCAL synchronous_commit TO OFF
ในการทำธุรกรรม
ด้วยการปรับเปลี่ยนไฟล์การกำหนดค่าเล็กน้อยนี้ เราให้ผู้ใช้สามารถควบคุมความสอดคล้องและประสิทธิภาพได้
ที่มา: will.com