สำหรับตัวเลือกการบีบอัดคอลัมน์ PostgreSQL 14 มีวิธีการบีบอัดแบบใหม่ LZ4 เมื่อเทียบกับวิธีการบีบอัด PGLZ ที่มีอยู่ใน TOAST แล้ว การบีบอัด LZ4 จะเร็วกว่า บทความนี้อธิบายวิธีใช้ตัวเลือกทั้งหมดและเปรียบเทียบประสิทธิภาพกับอัลกอริธึมการบีบอัดอื่นๆ
พื้นหลัง
ใน PG หน้าคือหน่วยเก็บข้อมูล และค่าเริ่มต้นคือ 8KB โดยทั่วไป แถวของข้อมูลไม่ได้รับอนุญาตให้จัดเก็บไว้ในหน้าต่างๆ อย่างไรก็ตาม มีประเภทข้อมูลความยาวผันแปรได้บางประเภท และข้อมูลที่เก็บไว้อาจเกินหน้าหนึ่งของมหาวิทยาลัย เพื่อที่จะเอาชนะข้อจำกัดทั้งหมด ฟิลด์ขนาดใหญ่จะถูกบีบอัดหรือแบ่งออกเป็นแถวทางกายภาพหลายแถว เทคนิคนี้คือ TOAST:
ตามค่าเริ่มต้น หากมีคอลัมน์ที่มีความยาวผันแปรได้ในตาราง และขนาดของข้อมูลแถวเกิน TOAST_TUPLE_THRESHOLD (ค่าเริ่มต้น 2KB) TOAST จะถูกทริกเกอร์ ขั้นแรก ข้อมูลจะถูกบีบอัดก่อน หากยังคงมีขนาดใหญ่เกินไปหลังจากการบีบอัด พื้นที่เก็บข้อมูลจะล้น ควรสังเกตว่าหากกลยุทธ์การจัดเก็บคอลัมน์ระบุ EXTERNAL/PLAIN การบีบอัดจะถูกห้าม
ก่อน PG14 TOAST จะรองรับอัลกอริธึมการบีบอัด PGLZ เดียวเท่านั้น (อัลกอริทึม PG ในตัว) แต่อัลกอริธึมการบีบอัดอื่นๆ อาจเร็วกว่า PGLZ หรือมีอัตราส่วนการอัดที่สูงกว่า มีตัวเลือกการบีบอัดใหม่ การบีบอัด LZ4 ใน PG14 ซึ่งเป็นอัลกอริธึมการบีบอัดแบบไม่สูญเสียที่รู้จักในด้านความเร็ว ดังนั้นเราจึงคาดได้ว่ามันจะช่วยเพิ่มความเร็วของการบีบอัดและคลายการบีบอัดของ TOAST
วิธีการใช้ LZ4?
ในการใช้คุณสมบัติการบีบอัด LZ4 คุณต้องระบุ -with-lz4 เมื่อทำการคอมไพล์ และทำตามไลบรารี LZ4 ในระบบปฏิบัติการ อัลกอริธึมการบีบอัดเริ่มต้นของ TOAST ของอินสแตนซ์ PG สามารถระบุได้ผ่านพารามิเตอร์ GUC default_toast_compression สามารถอยู่ใน postgresql กำหนดค่าใน conf คุณยังสามารถเปลี่ยนเฉพาะการเชื่อมต่อปัจจุบันผ่านคำสั่ง SET:
postgres＝＃ ค่าเริ่มต้นของ SET＿toast＿การบีบอัด＝lz4；
ตลาดหลักทรัพย์
ระบุอัลกอริทึมการบีบอัดคอลัมน์เมื่อสร้างตารางใน CREATE TABLE:
เราสามารถใช้คำสั่ง d+ เพื่อดูอัลกอริธึมการบีบอัดสำหรับคอลัมน์ทั้งหมด หากคอลัมน์ไม่รองรับหรือไม่ระบุอัลกอริธึมการบีบอัด จะมีการเว้นวรรคในคอลัมน์การบีบอัด ในตัวอย่างข้างต้น คอลัมน์ id ไม่รองรับอัลกอริธึมการบีบอัด คอลัมน์ col1 ใช้ PGLZ, col2 ใช้ LZ4 และ col3 ไม่ได้ระบุอัลกอริทึมการบีบอัด จากนั้นจะใช้อัลกอริธึมการบีบอัดเริ่มต้น
คุณสามารถแก้ไขอัลกอริธึมการบีบอัดคอลัมน์ผ่าน ALTER TABLE ได้ แต่ควรสังเกตว่าอัลกอริธึมที่แก้ไขจะมีผลกับข้อมูลการแทรกหลังจากดำเนินการคำสั่งทั้งหมดเท่านั้น
postgres＝＃ INSERT INTO tbl VALUES （1， ทำซ้ำ（＇abc＇，1000）， ทำซ้ำ（＇abc＇，1000），repeat（＇abc＇，1000））；
ใส่ 0 1
postgres＝＃ แก้ไขตาราง tbl แก้ไขคอลัมน์ col1 ตั้งค่าการบีบอัด lz4；
แก้ไขตาราง
postgres＝＃ INSERT INTO tbl VALUES （2， ทำซ้ำ（＇abc＇，1000）， ทำซ้ำ（＇abc＇，1000），repeat（＇abc＇，1000））；
ใส่ 0 1
postgres＝＃ เลือกรหัส，
postgres－＃ pg＿column＿compression (id) AS การบีบอัด＿colid，
postgres－＃ pg＿column＿compression(col1) AS การบีบอัด＿col1，
postgres－＃ pg＿column＿compression(col2) AS การบีบอัด＿col2，
postgres－＃ pg＿column＿compression(col3) AS การบีบอัด＿col3
postgres－＃ จาก tbl；
id ｜ การบีบอัด ＿colid ｜ การบีบอัด ＿col1 ｜ การบีบอัด ＿col2 ｜ การบีบอัด ＿col3
－－－－＋
1 ｜ ｜ pglz ｜ lz4 ｜ lz4
2 ｜ ｜ lz4 ｜ lz4 ｜ lz4
(2 แถว)
คุณจะเห็นว่าสำหรับแถวที่แทรกก่อนแก้ไขอัลกอริธึมการบีบอัด col1 ยังคงใช้อัลกอริธึมการบีบอัด PGLZ แม้ว่าอัลกอริธึมการบีบอัดจะถูกแก้ไขจาก PGLZ เป็น LZ4 (แล้วควรใช้อัลกอริธึมใดสำหรับการคลายการบีบอัดหลังจากแก้ไข)
โปรดทราบว่าหากคุณสแกนข้อมูลจากตารางอื่นและแทรกลงในตารางนี้ เช่น CREATE TABLE . . เช่น. . . หรือ INSERT INTO . . เลือก. . . , อัลกอริธึมการบีบอัดที่ใช้โดยข้อมูลที่แทรกยังคงใช้วิธีการบีบอัดของข้อมูลดั้งเดิม pg_dump และ pg_dumpall ยังเพิ่ม option-no-toast-compuression หลังจากใช้ตัวเลือกทั้งหมด ตัวเลือกการบีบอัด TOAST จะไม่ถูกทิ้ง
การเปรียบเทียบประสิทธิภาพ
ทดสอบอัตราการบีบอัดและความเร็วการบีบอัดของ LZ4 และ PGLZ และเพิ่มผลการทดสอบของข้อมูลที่ไม่บีบอัด (กลยุทธ์การจัดเก็บที่ระบุคือ EXTERNAL) สำหรับข้อมูลที่ไม่มีการบีบอัด จะไม่มีการบีบอัดและคลายการบีบอัดที่ใช้เวลานาน แต่เวลาในการอ่านและเขียนข้อมูลจะเพิ่มขึ้น
ข้อมูลที่ใช้ในการทดสอบ: เอกสาร PG (ไฟล์ HTML หนึ่งไฟล์ต่อบรรทัดข้อมูล); ข้อมูลที่จัดทำโดย SilesiaCorpus รวมถึง HTML, ข้อความ, ซอร์สโค้ด, ไฟล์ไบนารีที่เรียกใช้งานได้ และรูปภาพ
การใช้เครื่องทดสอบอินเทล? ซีออน? เงิน 4210 ซีพียู ＠2GHz พร้อม 20 คอร์／10 เธรด／20 ซ็อกเก็ต。
ใช้ pgbench เพื่อทดสอบเวลาดำเนินการของคำสั่ง SQL และ pg_table_size เพื่อตรวจสอบ table university (ดำเนินการ VACUUM FULL ก่อนดำเนินการแต่ละครั้งเพื่อขจัดอิทธิพลของบันทึกที่ไม่ทำงาน)
อัตราส่วนการบีบอัด
อัตราการบีบอัดของ PGLZ และ LZ4 ทั้งคู่ขึ้นอยู่กับข้อมูลที่ซ้ำกัน ยิ่งทูเพิลซ้ำมาก อัตราการบีบอัดก็จะยิ่งสูงขึ้น อย่างไรก็ตาม หาก PG ประเมินอัตราการบีบอัดว่าไม่ดี การบีบอัดจะไม่ถูกดำเนินการ แม้ว่าขนาดข้อมูลจะถึงเกณฑ์ก็ตาม เนื่องจากการบีบอัดไม่ได้ช่วยประหยัดพื้นที่ดิสก์อย่างมีประสิทธิภาพ จึงต้องใช้เวลาและทรัพยากรเพิ่มขึ้นสำหรับการล็อกการคลายการบีบอัด
ใน PG14 ปัจจุบัน PGLZ ต้องการอัตราส่วนการบีบอัดอย่างน้อย 25% ในขณะที่ LZ มีขนาดเล็กกว่าข้อมูลที่ไม่มีการบีบอัดเท่านั้น ฉันเปรียบเทียบขนาดของตาราง LZ4, PGLZ และตารางที่ไม่บีบอัด จะเห็นได้ว่าในสถานการณ์ส่วนใหญ่ อัตราการบีบอัดของ PGLZ จะดีกว่าเล็กน้อย อัตราการบีบอัดจะประเมินเป็น 2.23 และอัตราส่วนการอัดของ LZ4 คือ 2.07 ซึ่งหมายความว่า PGLZ สามารถประหยัดพื้นที่ดิสก์ได้ 7%
รูปที่ 1 － เปรียบเทียบขนาดตาราง （เป็น KB）
ความเร็วในการบีบอัด/คลายการบีบอัด
ข้อมูล TOAST จะถูกบีบอัดและคลายการบีบอัดในระหว่างการแทรกและการค้นหา ดังนั้นฉันจึงรันคำสั่ง SQL เพื่อดูผลกระทบของอัลกอริธึมการบีบอัดต่างๆ
ขั้นแรก ให้เปรียบเทียบประสิทธิภาพของคำสั่ง INSERT เมื่อใช้ LZ, PGLZ และไม่ใช้การบีบอัด จะเห็นได้ว่าเมื่อเปรียบเทียบกับข้อมูลที่ไม่บีบอัดแล้ว LZ4 จะใช้เวลามากกว่าเล็กน้อย และ PGLZ จะใช้เวลามากกว่า เวลาบีบอัดของ LZ4 น้อยกว่า PGLZ โดยเฉลี่ย 20% นี่คือการปรับปรุงที่สำคัญมาก
รูปที่ 2 － เปรียบเทียบประสิทธิภาพของ INSERT
เปรียบเทียบ SELECT ด้านล่าง เมื่อเปรียบเทียบกับ PGLZ แล้ว LZ4 สามารถประหยัดเวลาได้ 20% และไม่มีความแตกต่างมากนักเมื่อเทียบกับข้อมูลที่ไม่บีบอัด ค่าใช้จ่ายในการบีบอัดลดลงเหลือระดับต่ำมาก
รูปที่ 3 － เปรียบเทียบประสิทธิภาพของ SELECT
เปรียบเทียบคำสั่ง INSERT พร้อมกันของไคลเอ็นต์ 16 เครื่อง เมื่อเทียบกับ PGLZ ประสิทธิภาพการบีบอัดไฟล์ขนาดใหญ่เดียว (HTML, ข้อความภาษาอังกฤษ, ซอร์สโค้ด, ไฟล์ปฏิบัติการแบบไบนารี, รูปภาพ) โดยใช้ LZ4 เร็วขึ้น 60% -70% แทรกไฟล์ขนาดเล็กหลายไฟล์ (ไฟล์ PG) ประสิทธิภาพไม่ดีขึ้น เมื่อเทียบกับข้อมูลที่ไม่มีการบีบอัด มีการปรับปรุงอย่างมาก คาดว่าการใช้การบีบอัดจะช่วยลดปริมาณข้อมูลที่เขียนลงดิสก์
รูปที่ 4 － เปรียบเทียบประสิทธิภาพของ INSERT กับไคลเอนต์ 16 ตัว
ด้วยไคลเอ็นต์ SELECT 16 ตัว LZ4 ทำงานได้ดีกว่า PGLZ ในสถานการณ์ส่วนใหญ่:
รูปที่ 5 － เปรียบเทียบประสิทธิภาพของ SELECT กับ 16 ไคลเอนต์
นอกจากนี้ยังเปรียบเทียบความเร็วของการประมวลผลข้อความโดยใช้ฟังก์ชันสตริง SELECT และ UPDATE LZ4 ดีกว่า PGLZ ทั้งฉาก เมื่อเทียบกับข้อมูลที่ไม่มีการบีบอัด ข้อมูลของอัลกอริธึมการบีบอัด LZ4 มีความเร็วในการประมวลผลฟังก์ชันเกือบเท่ากัน และอัลกอริธึม LZ4 แทบไม่ส่งผลต่อความเร็วในการทำงานของสตริง
รูปที่ 6 － เปรียบเทียบประสิทธิภาพโดยใช้ฟังก์ชันสตริง
เมื่อเปรียบเทียบกับ PGLZ แล้ว LZ4 จะบีบอัดและคลายการบีบอัดข้อมูล TOAST ได้อย่างมีประสิทธิภาพมากขึ้นและให้ประสิทธิภาพที่ดี เมื่อเทียบกับข้อมูลที่ไม่มีการบีบอัด ความเร็วในการสืบค้นเกือบจะเท่ากัน และเมื่อเทียบกับ PGLZ การแทรกจะเร็วกว่า 80% แน่นอน อัตราการบีบอัดไม่ค่อยดีในบางสถานการณ์ แต่ถ้าคุณต้องการเพิ่มความเร็วในการดำเนินการ ขอแนะนำอย่างยิ่งให้ใช้อัลกอริธึม LZ4
ยังต้องให้ความสนใจ ต้องพิจารณาว่าข้อมูลในตารางเหมาะสมกับการบีบอัดหรือไม่ ถ้าอัตราส่วนกำลังอัดไม่ดีก็จะพยายามอัดตัวเลขแล้วยอมแพ้ ซึ่งจะส่งผลเพิ่มเติมแรมทรัพยากรเสียและส่งผลอย่างมากต่อความเร็วในการแทรกข้อมูล
อนาคต
LZ4 ได้ปรับปรุงประสิทธิภาพการบีบอัดและคลายการบีบอัดของ TOAST อย่างมาก นอกจาก LZ4 แล้ว ยังมีอัลกอริธึมการบีบอัดอื่นๆ อีกมากมาย เช่น Zstandard ผู้ใช้ที่รองรับ Zstandard จะได้รับอัตราการบีบอัดที่ดีกว่า PGLZ LZ4 HC มีความเร็วการบีบอัด 98.5% เมื่อเทียบกับการบีบอัด LZ4 แต่สามารถเพิ่มอัตราการบีบอัดได้อย่างมาก หวังว่า PG เวอร์ชันอนาคตจะสามารถใช้อัลกอริธึมการบีบอัดได้มากขึ้น
นอกจาก TOAST แล้ว ฉากอื่นๆ ยังต้องถูกบีบอัดด้วย เท่าที่ฉันรู้ เวอร์ชันการพัฒนาปัจจุบันรองรับการบีบอัด LZ4 ของ WAL แล้ว ซึ่งเป็นคุณสมบัติที่น่าตื่นเต้น