“ฐานข้อมูลเชิงสัมพันธ์แบบโอเพ่นซอร์สที่ดีที่สุดในโลก” เวอร์ชันล่าสุดจะออกมาในอีกไม่กี่สัปดาห์ข้างหน้า (หากทุกอย่างเป็นไปตามแผน) สิ่งนี้เป็นไปตามกำหนดการปกติของการเปิดตัวเวอร์ชันใหม่พร้อมฟีเจอร์ใหม่มากมายปีละครั้ง และตรงไปตรงมา นั่นน่าประทับใจมาก นั่นเป็นเหตุผลที่ฉันกลายเป็นสมาชิกของชุมชน PostgreSQL
ในความคิดของฉัน PostgreSQL 12 ไม่เหมือนกับรีลีสก่อนหน้านี้ตรงที่ไม่มีฟีเจอร์ที่ปฏิวัติวงการหนึ่งหรือสองฟีเจอร์ (เช่น การแบ่งพาร์ติชั่นหรือการสืบค้นแบบขนาน) ฉันเคยพูดติดตลกว่าฟีเจอร์หลักของ PostgreSQL 12 คือความเสถียรที่มากกว่า นั่นคือสิ่งที่คุณต้องการเมื่อคุณจัดการข้อมูลสำคัญของธุรกิจของคุณใช่หรือไม่
แต่ PostgreSQL 12 ไม่ได้หยุดอยู่แค่นั้น ด้วยคุณสมบัติและการปรับปรุงใหม่ๆ แอปพลิเคชันจะทำงานได้ดีขึ้น และสิ่งที่คุณต้องทำคืออัพเกรด!
(อาจจะสร้างดัชนีขึ้นมาใหม่ แต่ในรุ่นนี้ มันไม่น่ากลัวเท่าที่เราคุ้นเคย)
จะเป็นการดีอย่างยิ่งหากอัปเกรด PostgreSQL และเพลิดเพลินกับการปรับปรุงที่สำคัญทันทีโดยไม่ต้องยุ่งยากโดยไม่จำเป็น ไม่กี่ปีที่ผ่านมา ฉันได้ตรวจสอบการอัปเกรดจาก PostgreSQL 9.4 เป็น PostgreSQL 10 และได้เห็นว่าแอปพลิเคชันเร่งความเร็วได้อย่างไรด้วยการปรับปรุงการทำงานคู่ขนานของคิวรีใน PostgreSQL 10 และที่สำคัญที่สุด ฉันแทบไม่ต้องทำอะไรเลย (เพียงตั้งค่าพารามิเตอร์การกำหนดค่า max_parallel_workers).
ยอมรับว่าจะสะดวกเมื่อแอปพลิเคชันทำงานได้ดีขึ้นทันทีหลังจากการอัปเกรด และเราพยายามอย่างหนักเพื่อทำให้ผู้ใช้พอใจ เนื่องจาก PostgreSQL มีผู้ใช้มากขึ้นเรื่อยๆ
แล้วการอัพเกรดเป็น PostgreSQL 12 อย่างง่ายๆ จะทำให้คุณมีความสุขได้อย่างไร? ฉันจะบอกคุณตอนนี้
การปรับปรุงการจัดทำดัชนีที่สำคัญ
หากไม่มีการจัดทำดัชนี ฐานข้อมูลจะอยู่ไม่ไกล คุณจะหาข้อมูลได้อย่างรวดเร็วได้อย่างไร? ชื่อระบบการจัดทำดัชนีพื้นฐานของ PostgreSQL . ดัชนีประเภทนี้ได้รับการปรับให้เหมาะสมสำหรับระบบจัดเก็บข้อมูล
เราก็ใช้โอเปอเรเตอร์ CREATE INDEX ON some_table (some_column)และ PostgreSQL ทำงานหลายอย่างเพื่อให้ดัชนีอัปเดตอยู่เสมอในขณะที่เราแทรก อัปเดต และลบค่าอยู่ตลอดเวลา ทุกอย่างทำงานได้ด้วยตัวเองราวกับมีเวทมนตร์
แต่ดัชนี PostgreSQL มีปัญหาอย่างหนึ่งนั่นคือพวกมัน และใช้พื้นที่ดิสก์เพิ่มเติมและลดประสิทธิภาพในการดึงและอัปเดตข้อมูล โดย "บวม" ฉันหมายถึงการรักษาโครงสร้างดัชนีอย่างไม่มีประสิทธิภาพ สิ่งนี้อาจจะหรืออาจจะไม่เกี่ยวข้องกับสิ่งอันดับขยะที่มันลบออก (ขอบคุณ Peter Gaghan สำหรับข้อมูล))). การขยายตัวของดัชนีจะสังเกตเห็นได้ชัดเจนเป็นพิเศษในปริมาณงานที่ดัชนีมีการเปลี่ยนแปลงอย่างต่อเนื่อง
PostgreSQL 12 ปรับปรุงประสิทธิภาพของดัชนี B-tree อย่างมาก และการทดลองกับเกณฑ์มาตรฐานเช่น TPC-C แสดงให้เห็นว่าขณะนี้ใช้พื้นที่น้อยลงโดยเฉลี่ย 40% ตอนนี้เราใช้เวลาน้อยลงไม่เพียงแต่ในการรักษาดัชนี B-tree (นั่นคือในการดำเนินการเขียน) แต่ยังรวมถึงการดึงข้อมูลด้วย เนื่องจากดัชนีมีขนาดเล็กกว่ามาก
แอปพลิเคชันที่อัปเดตตารางอย่างต่อเนื่อง - โดยทั่วไปคือแอปพลิเคชัน OLTP () - จะใช้ดิสก์และประมวลผลคำขออย่างมีประสิทธิภาพมากขึ้น ยิ่งพื้นที่ดิสก์มากขึ้น ฐานข้อมูลก็ยิ่งต้องขยายพื้นที่มากขึ้นโดยไม่ต้องอัปเกรดโครงสร้างพื้นฐาน
กลยุทธ์การอัปเกรดบางอย่างจำเป็นต้องสร้างดัชนี B-tree ใหม่เพื่อใช้ประโยชน์จากสิทธิประโยชน์เหล่านี้ (เช่น จะไม่สร้างดัชนีใหม่โดยอัตโนมัติ) ใน PostgreSQL เวอร์ชันก่อนหน้า การสร้างดัชนีขนาดใหญ่ขึ้นใหม่บนตารางส่งผลให้เกิดการหยุดทำงานอย่างมีนัยสำคัญ เนื่องจากไม่สามารถทำการเปลี่ยนแปลงได้ในระหว่างนี้ แต่ PostgreSQL 12 มีฟีเจอร์เจ๋งๆ อีกประการหนึ่ง นั่นคือ ตอนนี้คุณสามารถสร้างดัชนีใหม่ควบคู่ไปกับคำสั่งได้แล้ว เพื่อหลีกเลี่ยงการหยุดทำงานโดยสิ้นเชิง
มีการปรับปรุงอื่นๆ ในโครงสร้างพื้นฐานการจัดทำดัชนีใน PostgreSQL 12 อีกสิ่งหนึ่งที่มีเวทย์มนตร์ - หรือที่เรียกว่า WAL (บันทึกการเขียนล่วงหน้า) บันทึกการเขียนล่วงหน้าจะบันทึกทุกธุรกรรมใน PostgreSQL ในกรณีที่เกิดความล้มเหลวและการจำลองแบบ แอปพลิเคชั่นใช้สำหรับการเก็บถาวรและ . แน่นอนว่าบันทึกการเขียนล่วงหน้าจะถูกเขียนลงดิสก์ ซึ่งอาจส่งผลต่อประสิทธิภาพการทำงาน
PostgreSQL 12 ได้ลดค่าใช้จ่ายของบันทึก WAL ที่สร้างโดยดัชนี GiST, GIN และ SP-GiST ในระหว่างการสร้างดัชนี สิ่งนี้ให้ประโยชน์ที่จับต้องได้หลายประการ: บันทึก WAL ใช้พื้นที่ดิสก์น้อยลง และข้อมูลจะถูกเล่นซ้ำเร็วขึ้น เช่น ในระหว่างการกู้คืนระบบหรือการกู้คืนแบบ point-in-time หากคุณใช้ดัชนีดังกล่าวในแอปพลิเคชันของคุณ (เช่น แอปพลิเคชันภูมิสารสนเทศที่ใช้ PostGIS จะใช้ดัชนี GiST เป็นจำนวนมาก) นี่ก็เป็นอีกคุณสมบัติหนึ่งที่จะปรับปรุงประสบการณ์ได้อย่างมากโดยไม่ต้องใช้ความพยายามใดๆ ในส่วนของคุณ
การแบ่งพาร์ติชัน - ใหญ่ขึ้น ดีขึ้น เร็วขึ้น
เปิดตัว PostgreSQL 10 . ใน PostgreSQL 11 มันใช้งานง่ายขึ้นมาก ใน PostgreSQL 12 คุณสามารถเปลี่ยนขนาดของส่วนต่างๆ ได้
ใน PostgreSQL 12 ประสิทธิภาพของระบบการแบ่งพาร์ติชั่นดีขึ้นอย่างเห็นได้ชัด โดยเฉพาะอย่างยิ่งหากมีพาร์ติชั่นนับพันในตาราง ตัวอย่างเช่น หากแบบสอบถามส่งผลต่อพาร์ติชั่นเพียงไม่กี่พาร์ติชั่นในตารางที่มีพาร์ติชั่นนับพันพาร์ติชั่น จะดำเนินการเร็วขึ้นมาก ไม่ใช่แค่การปรับปรุงประสิทธิภาพสำหรับข้อความค้นหาประเภทนี้เท่านั้น คุณจะสังเกตได้ว่าการดำเนินการ INSERT รวดเร็วเพียงใดบนตารางที่มีหลายพาร์ติชัน
การบันทึกข้อมูลโดยใช้ - อย่างไรก็ตาม นี่เป็นวิธีที่ยอดเยี่ยม และนี่คือตัวอย่าง — ตารางที่แบ่งพาร์ติชันใน PostgreSQL 12 ก็มีประสิทธิภาพมากขึ้นเช่นกัน ด้วยการ COPY ทุกอย่างรวดเร็วอยู่แล้ว แต่ใน PostgreSQL 12 มันบินได้อย่างแน่นอน
ด้วยข้อดีเหล่านี้ PostgreSQL จึงช่วยให้คุณจัดเก็บชุดข้อมูลขนาดใหญ่ขึ้นและเรียกข้อมูลได้ง่ายขึ้น และไม่มีความพยายามในส่วนของคุณ หากแอพพลิเคชั่นมีหลายพาร์ติชั่น เช่น การบันทึกข้อมูลอนุกรมเวลา การอัพเกรดง่ายๆ จะช่วยปรับปรุงประสิทธิภาพได้อย่างมาก
แม้ว่านี่จะไม่ใช่การปรับปรุงแบบ "อัปเกรดและเพลิดเพลิน" เสียทีเดียว แต่ PostgreSQL 12 จะช่วยให้คุณสร้างคีย์นอกที่อ้างอิงถึงตารางที่แบ่งพาร์ติชันได้ ทำให้การแบ่งพาร์ติชันเป็นเรื่องน่ายินดีในการทำงานด้วย
ด้วยแบบสอบถามดีขึ้นมาก
เมื่อ (หรือที่เรียกว่า CTE หรือที่เรียกว่า WITH query) ฉันแทบรอไม่ไหวที่จะเขียนบทความเกี่ยวกับ . นี่เป็นหนึ่งในคุณสมบัติที่จะเร่งความเร็วแอปพลิเคชัน ยกเว้นกรณีที่คุณใช้ CTE
ฉันมักจะพบว่ามือใหม่ที่ใช้ SQL ชอบใช้ CTE หากคุณเขียนด้วยวิธีใดวิธีหนึ่ง คุณจะรู้สึกเหมือนกำลังเขียนโปรแกรมที่จำเป็นจริงๆ โดยส่วนตัวแล้ว ฉันชอบเขียนคำถามเหล่านี้ใหม่เพื่อแก้ไข ไม่มี CTE และเพิ่มผลผลิต ตอนนี้ทุกอย่างแตกต่างออกไป
PostgreSQL 12 ช่วยให้คุณสามารถอินไลน์ CTE ประเภทใดประเภทหนึ่งโดยเฉพาะได้โดยไม่มีผลข้างเคียง (SELECT) ซึ่งใช้เพียงครั้งเดียวเมื่อใกล้สิ้นสุดคำขอ หากฉันติดตามข้อความค้นหา CTE ที่ฉันเขียนใหม่ ข้อความค้นหาส่วนใหญ่จะอยู่ในหมวดหมู่นี้ สิ่งนี้ช่วยให้นักพัฒนาเขียนโค้ดที่ชัดเจนซึ่งตอนนี้ยังทำงานได้อย่างรวดเร็วอีกด้วย
ยิ่งไปกว่านั้น PostgreSQL 12 ยังปรับการดำเนินการ SQL ให้เหมาะสมโดยที่คุณไม่ต้องทำอะไรเลย และแม้ว่าฉันอาจไม่จำเป็นต้องเพิ่มประสิทธิภาพการสืบค้นดังกล่าวในตอนนี้ แต่ก็เป็นเรื่องดีที่ PostgreSQL ยังคงทำงานในการเพิ่มประสิทธิภาพการสืบค้นต่อไป
Just-in-Time (JIT) - ตอนนี้เป็นค่าเริ่มต้น
บนระบบ PostgreSQL 12 ที่รองรับ การคอมไพล์ JIT ถูกเปิดใช้งานตามค่าเริ่มต้น ก่อนอื่น คุณจะได้รับการสนับสนุน สำหรับการดำเนินการภายในบางอย่าง และประการที่สอง การสืบค้นที่มีนิพจน์ (ตัวอย่างที่ง่ายที่สุดคือ x + y) ในรายการที่เลือก (ซึ่งคุณมีหลัง SELECT) การรวม นิพจน์ที่มีส่วนคำสั่ง WHERE และอื่นๆ สามารถใช้ JIT เพื่อปรับปรุงประสิทธิภาพได้
เนื่องจาก JIT ถูกเปิดใช้งานตามค่าเริ่มต้นใน PostgreSQL 12 ประสิทธิภาพจึงได้รับการปรับปรุงด้วยตัวเอง แต่ฉันขอแนะนำให้ทดสอบแอปพลิเคชันใน PostgreSQL 11 ซึ่งเปิดตัว JIT เพื่อวัดประสิทธิภาพการสืบค้นและดูว่าคุณจำเป็นต้องปรับแต่งสิ่งใดหรือไม่
แล้วฟีเจอร์ใหม่ที่เหลือใน PostgreSQL 12 ล่ะ?
PostgreSQL 12 มีคุณสมบัติใหม่เจ๋งๆ มากมาย ตั้งแต่ความสามารถในการตรวจสอบข้อมูล JSON โดยใช้นิพจน์เส้นทาง SQL/JSON มาตรฐาน ไปจนถึงการตรวจสอบสิทธิ์แบบหลายปัจจัยด้วยพารามิเตอร์ clientcert=verify-fullสร้างคอลัมน์ และอื่นๆ อีกมากมาย แยกกระทู้ก็พอแล้ว
เช่นเดียวกับ PostgreSQL 10 PostgreSQL 12 จะปรับปรุงประสิทธิภาพโดยรวมทันทีหลังจากการอัปเกรด แน่นอน คุณสามารถมีวิธีของคุณเองได้ - ทดสอบแอปพลิเคชันภายใต้เงื่อนไขที่คล้ายกันบนระบบที่ใช้งานจริงก่อนที่จะเปิดใช้งานการปรับปรุง เช่นเดียวกับที่ฉันทำกับ PostgreSQL 10 แม้ว่า PostgreSQL 12 จะมีเสถียรภาพมากกว่าที่ฉันคาดไว้อยู่แล้ว แต่อย่าเกียจคร้านในการทดสอบ ประยุกต์ใช้อย่างละเอียดก่อนปล่อยสู่การผลิต
ที่มา: will.com