เมื่อทำงานกับข้อมูลจำนวนมาก บางครั้งปัญหาการขาดพื้นที่ดิสก์อาจเกิดขึ้นได้ วิธีหนึ่งในการแก้ปัญหานี้คือการบีบอัดซึ่งทำให้คุณสามารถเพิ่มปริมาณการจัดเก็บข้อมูลได้บนอุปกรณ์เดียวกัน ในบทความนี้ เราจะมาดูว่าการบีบอัดข้อมูลทำงานอย่างไรใน Apache Ignite บทความนี้จะอธิบายเฉพาะวิธีการบีบอัดดิสก์ที่นำมาใช้ภายในผลิตภัณฑ์ วิธีอื่นในการบีบอัดข้อมูล (ผ่านเครือข่าย ในหน่วยความจำ) ไม่ว่าจะนำไปใช้หรือไม่ก็ตาม จะยังคงอยู่นอกขอบเขต
ดังนั้น เมื่อเปิดใช้งานโหมดคงอยู่ ซึ่งเป็นผลมาจากการเปลี่ยนแปลงข้อมูลในแคช Ignite จึงเริ่มเขียนลงดิสก์:
- เนื้อหาของแคช
- เขียนบันทึกล่วงหน้า (ต่อไปนี้จะเรียกว่า WAL)
มีกลไกสำหรับการบีบอัด WAL มาระยะหนึ่งแล้ว เรียกว่าการบดอัด WAL Apache Ignite 2.8 ที่เพิ่งเปิดตัวแนะนำกลไกเพิ่มเติมอีกสองกลไกที่ช่วยให้คุณสามารถบีบอัดข้อมูลบนดิสก์: การบีบอัดหน้าดิสก์สำหรับการบีบอัดเนื้อหาของแคช และการบีบอัดสแน็ปช็อตหน้า WAL สำหรับการบีบอัดรายการ WAL บางรายการ รายละเอียดเพิ่มเติมเกี่ยวกับกลไกทั้งสามด้านล่างนี้
การบีบอัดหน้าดิสก์
Какэтоработает
ก่อนอื่น มาดูกันสั้นๆ ว่า Ignite เก็บข้อมูลอย่างไร หน่วยความจำหน้าใช้สำหรับการจัดเก็บ ขนาดเพจถูกตั้งค่าไว้ที่จุดเริ่มต้นของโหนดและไม่สามารถเปลี่ยนแปลงได้ในภายหลัง นอกจากนี้ ขนาดเพจต้องเป็นกำลังของสองและเป็นผลคูณของขนาดบล็อกระบบไฟล์ หน้าจะถูกโหลดจากดิสก์ลงใน RAM ตามความจำเป็น ขนาดของข้อมูลบนดิสก์อาจเกินจำนวน RAM ที่จัดสรร หาก RAM มีพื้นที่ไม่เพียงพอที่จะโหลดเพจจากดิสก์ เพจเก่าที่ไม่ได้ใช้อีกต่อไปจะถูกลบออกจาก RAM
ข้อมูลจะถูกเก็บไว้ในดิสก์ในรูปแบบต่อไปนี้: ไฟล์แยกต่างหากจะถูกสร้างขึ้นสำหรับแต่ละพาร์ติชันของแต่ละกลุ่มแคช ในไฟล์นี้ เพจต่างๆ จะปรากฏขึ้นทีละหน้าตามลำดับดัชนีจากน้อยไปหามาก ตัวระบุเพจแบบเต็มประกอบด้วยตัวระบุกลุ่มแคช หมายเลขพาร์ติชัน และดัชนีเพจในไฟล์ ดังนั้น เมื่อใช้ตัวระบุเพจแบบเต็ม เราจึงสามารถกำหนดไฟล์และออฟเซ็ตในไฟล์สำหรับแต่ละเพจได้โดยไม่ซ้ำกัน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับหน่วยความจำเพจได้ในบทความ Apache Ignite Wiki: .
กลไกการบีบอัดดิสก์เพจดังที่คุณอาจเดาได้จากชื่อนั้นทำงานในระดับเพจ เมื่อเปิดใช้งานกลไกนี้ ข้อมูลใน RAM จะถูกประมวลผลตามที่เป็นอยู่ โดยไม่มีการบีบอัดใดๆ แต่เมื่อเพจถูกบันทึกจาก RAM ลงดิสก์ ข้อมูลเหล่านั้นจะถูกบีบอัด
แต่การบีบอัดแต่ละหน้าแยกกันไม่ใช่วิธีแก้ปัญหาคุณต้องลดขนาดของไฟล์ข้อมูลที่ได้ หากขนาดหน้าไม่คงที่อีกต่อไป เราไม่สามารถเขียนหน้าไปยังไฟล์ทีละหน้าได้อีกต่อไป เนื่องจากอาจทำให้เกิดปัญหาหลายประการ:
- เมื่อใช้ดัชนีหน้า เราจะไม่สามารถคำนวณออฟเซ็ตที่อยู่ในไฟล์ได้
- ยังไม่ชัดเจนว่าจะทำอย่างไรกับเพจที่ไม่ได้อยู่ท้ายไฟล์และเปลี่ยนขนาด หากขนาดหน้าลดลง พื้นที่ว่างที่ว่างจะหายไป หากขนาดหน้าเพิ่มขึ้น คุณจะต้องค้นหาตำแหน่งใหม่ในไฟล์
- หากเพจเลื่อนไปเป็นจำนวนไบต์ซึ่งไม่ใช่หลายเท่าของขนาดบล็อกระบบไฟล์ การอ่านหรือเขียนหน้านั้นจะต้องแตะบล็อกระบบไฟล์อีกหนึ่งบล็อก ซึ่งอาจส่งผลให้ประสิทธิภาพลดลง
เพื่อหลีกเลี่ยงการแก้ปัญหาเหล่านี้ในระดับของตัวเอง การบีบอัดดิสก์เพจใน Apache Ignite จะใช้กลไกระบบไฟล์ที่เรียกว่าไฟล์กระจัดกระจาย ไฟล์กระจัดกระจายเป็นไฟล์ที่สามารถทำเครื่องหมายขอบเขตที่เติมศูนย์เป็น "หลุม" ได้ ในกรณีนี้ จะไม่มีการจัดสรรบล็อกระบบไฟล์เพื่อจัดเก็บรูเหล่านี้ ส่งผลให้ประหยัดพื้นที่ดิสก์
เป็นเหตุผลที่เพื่อที่จะเพิ่มบล็อกระบบไฟล์ขนาดของรูจะต้องมากกว่าหรือเท่ากับบล็อกระบบไฟล์ซึ่งกำหนดข้อ จำกัด เพิ่มเติมเกี่ยวกับขนาดหน้าและ Apache Ignite: เพื่อให้การบีบอัดมีผลใด ๆ ขนาดหน้าจะต้องใหญ่กว่าขนาดของบล็อกระบบไฟล์อย่างเคร่งครัด หากขนาดหน้าเท่ากับขนาดบล็อก เราจะไม่สามารถปล่อยบล็อกเดียวได้ เนื่องจากในการที่จะเพิ่มบล็อกเดียว หน้าที่บีบอัดต้องใช้พื้นที่ 0 ไบต์ หากขนาดหน้าเท่ากับขนาด 2 หรือ 4 บล็อก เราจะสามารถเพิ่มพื้นที่ว่างได้อย่างน้อยหนึ่งบล็อกหากหน้าของเราถูกบีบอัดอย่างน้อย 50% หรือ 75% ตามลำดับ
ดังนั้นคำอธิบายขั้นสุดท้ายเกี่ยวกับวิธีการทำงานของกลไก: เมื่อเขียนเพจลงดิสก์ จะมีการพยายามบีบอัดเพจ หากขนาดของเพจที่ถูกบีบอัดอนุญาตให้บล็อกระบบไฟล์ตั้งแต่หนึ่งบล็อกขึ้นไปถูกปล่อย เพจนั้นจะถูกเขียนในรูปแบบบีบอัด และจะมีการสร้าง "รู" แทนที่บล็อกที่ถูกปล่อย (การเรียกระบบจะถูกดำเนินการ fallocate() พร้อมธงเจาะรู) หากขนาดของเพจที่บีบอัดไม่อนุญาตให้บล็อกถูกปล่อย เพจจะถูกบันทึกตามที่เป็นอยู่ ไม่มีการบีบอัด การชดเชยหน้าทั้งหมดจะถูกคำนวณในลักษณะเดียวกับที่ไม่มีการบีบอัด โดยการคูณดัชนีหน้าด้วยขนาดหน้า ไม่จำเป็นต้องย้ายหน้าเพจด้วยตนเอง การชดเชยหน้าจะตกอยู่ภายใต้ขอบเขตของบล็อกระบบไฟล์ เช่นเดียวกับที่ไม่มีการบีบอัด
ในการใช้งานปัจจุบัน Ignite สามารถทำงานกับไฟล์กระจัดกระจายภายใต้ Linux OS เท่านั้น ดังนั้น การบีบอัดหน้าดิสก์สามารถเปิดใช้งานได้เมื่อใช้ Ignite บนระบบปฏิบัติการนี้เท่านั้น
อัลกอริธึมการบีบอัดที่สามารถใช้สำหรับการบีบอัดหน้าดิสก์: ZSTD, LZ4, Snappy นอกจากนี้ยังมีโหมดการทำงาน (SKIP_GARBAGE) ซึ่งเฉพาะพื้นที่ที่ไม่ได้ใช้ในหน้าเท่านั้นที่จะถูกโยนออกไปโดยไม่ต้องใช้การบีบอัดข้อมูลที่เหลือ ซึ่งจะช่วยลดภาระบน CPU เมื่อเทียบกับอัลกอริธึมที่ระบุไว้ก่อนหน้านี้
ผลกระทบต่อประสิทธิภาพ
น่าเสียดายที่ฉันไม่ได้ทำการวัดประสิทธิภาพจริงบนอัฒจันทร์จริง เนื่องจากเราไม่ได้วางแผนที่จะใช้กลไกนี้ในการผลิต แต่ในทางทฤษฎีเราสามารถคาดเดาได้ว่าเราจะแพ้ที่ไหนและเราจะชนะที่ไหน
ในการทำเช่นนี้ เราต้องจำไว้ว่ามีการอ่านและเขียนหน้าเว็บอย่างไรเมื่อมีการเข้าถึง:
- เมื่อดำเนินการอ่าน จะถูกค้นหาใน RAM ก่อน หากการค้นหาไม่สำเร็จ เพจจะถูกโหลดลงใน RAM จากดิสก์โดยใช้เธรดเดียวกันกับที่ทำการอ่าน
- เมื่อดำเนินการเขียน เพจใน RAM จะถูกทำเครื่องหมายว่าสกปรก แต่เพจจะไม่ถูกบันทึกลงดิสก์ทันทีโดยเธรดที่ทำการเขียน เพจสกปรกทั้งหมดจะถูกบันทึกลงในดิสก์ในภายหลังในกระบวนการจุดตรวจสอบในเธรดที่แยกจากกัน
ดังนั้นผลกระทบต่อการดำเนินการอ่านคือ:
- ค่าบวก (ดิสก์ IO) เนื่องจากจำนวนบล็อกระบบไฟล์การอ่านลดลง
- เชิงลบ (CPU) เนื่องจากระบบปฏิบัติการต้องการโหลดเพิ่มเติมเพื่อทำงานกับไฟล์กระจัดกระจาย อาจเป็นไปได้ว่าการดำเนินการ IO เพิ่มเติมจะปรากฏขึ้นที่นี่โดยปริยายเพื่อบันทึกโครงสร้างไฟล์กระจัดกระจายที่ซับซ้อนมากขึ้น (น่าเสียดายที่ฉันไม่คุ้นเคยกับรายละเอียดทั้งหมดเกี่ยวกับวิธีการทำงานของไฟล์กระจัดกระจาย)
- เชิงลบ (CPU) เนื่องจากจำเป็นต้องขยายขนาดหน้า
- ไม่มีผลกระทบต่อการดำเนินการเขียน
- ผลกระทบต่อกระบวนการจุดตรวจ (ทุกอย่างที่นี่คล้ายกับการดำเนินการอ่าน):
- ค่าบวก (ดิสก์ IO) เนื่องจากจำนวนบล็อกระบบไฟล์ที่เขียนลดลง
- เชิงลบ (CPU, อาจเป็นดิสก์ IO) เนื่องจากการทำงานกับไฟล์กระจัดกระจาย
- เชิงลบ (CPU) เนื่องจากความจำเป็นในการบีบอัดหน้า
เครื่องชั่งด้านไหนจะเอียงเครื่องชั่ง? ทั้งหมดนี้ขึ้นอยู่กับสภาพแวดล้อมเป็นอย่างมาก แต่ฉันมีแนวโน้มที่จะเชื่อว่าการบีบอัดดิสก์เพจมีแนวโน้มที่จะทำให้ประสิทธิภาพลดลงในระบบส่วนใหญ่ นอกจากนี้ การทดสอบ DBMS อื่นๆ ที่ใช้วิธีการคล้ายกันกับไฟล์แบบกระจัดกระจายแสดงประสิทธิภาพที่ลดลงเมื่อเปิดใช้งานการบีบอัด
วิธีเปิดใช้งานและกำหนดค่า
ตามที่กล่าวไว้ข้างต้น Apache Ignite เวอร์ชันขั้นต่ำที่รองรับการบีบอัดดิสก์เพจคือ 2.8 และรองรับเฉพาะระบบปฏิบัติการ Linux เท่านั้น เปิดใช้งานและกำหนดค่าดังนี้:
- จะต้องมีโมดูลการบีบอัดจุดชนวนในคลาสพาธ ตามค่าเริ่มต้น จะอยู่ในการกระจาย Apache Ignite ในไดเร็กทอรี libs/ทางเลือก และไม่รวมอยู่ในคลาสพาธ คุณสามารถย้ายไดเร็กทอรีขึ้นไปหนึ่งระดับไปที่ libs จากนั้นเมื่อคุณรันไดเร็กทอรีผ่าน ignite.sh ไดเร็กทอรีจะถูกเปิดใช้งานโดยอัตโนมัติ
- ต้องเปิดใช้งานความคงอยู่ (เปิดใช้งานผ่าน
DataRegionConfiguration.setPersistenceEnabled(true)). - ขนาดหน้าจะต้องใหญ่กว่าขนาดบล็อกของระบบไฟล์ (คุณสามารถตั้งค่าได้โดยใช้
DataStorageConfiguration.setPageSize()). - สำหรับแต่ละแคชที่จำเป็นต้องบีบอัดข้อมูล คุณต้องกำหนดค่าวิธีการบีบอัดและ (เป็นทางเลือก) ระดับการบีบอัด (วิธี
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
การบดอัด WAL
Какэтоработает
WAL คืออะไร และเหตุใดจึงจำเป็น สั้นมาก: นี่คือบันทึกที่ประกอบด้วยเหตุการณ์ทั้งหมดที่เปลี่ยนพื้นที่จัดเก็บหน้าในท้ายที่สุด จำเป็นเป็นหลักเพื่อให้สามารถฟื้นตัวได้ในกรณีที่ล้ม การดำเนินการใดๆ ก่อนที่จะให้การควบคุมแก่ผู้ใช้ จะต้องบันทึกเหตุการณ์ใน WAL ก่อน เพื่อว่าในกรณีที่เกิดความล้มเหลว จะสามารถเล่นกลับในบันทึกและกู้คืนการดำเนินการทั้งหมดที่ผู้ใช้ได้รับการตอบกลับสำเร็จ แม้ว่าการดำเนินการเหล่านี้ ไม่มีเวลาที่จะสะท้อนให้เห็นในการจัดเก็บเพจบนดิสก์ (ข้างต้นแล้ว มีการอธิบายไว้แล้วว่าการเขียนจริงไปยังที่เก็บเพจเสร็จสิ้นในกระบวนการที่เรียกว่า "จุดตรวจสอบ" โดยมีความล่าช้าเล็กน้อยโดยเธรดที่แยกจากกัน)
รายการใน WAL แบ่งออกเป็นเชิงตรรกะและเชิงกายภาพ บูลีนคือกุญแจและค่านิยมในตัวมันเอง ทางกายภาพ - สะท้อนถึงการเปลี่ยนแปลงของเพจในร้านเพจ แม้ว่าบันทึกทางลอจิคัลจะมีประโยชน์ในบางกรณี แต่บันทึกทางกายภาพจำเป็นสำหรับการกู้คืนในกรณีที่เกิดอุบัติเหตุเท่านั้น และบันทึกจำเป็นตั้งแต่จุดตรวจที่สำเร็จครั้งล่าสุดเท่านั้น ที่นี่เราจะไม่ลงรายละเอียดและอธิบายว่าเหตุใดจึงทำงานในลักษณะนี้ แต่ผู้ที่สนใจสามารถดูบทความที่กล่าวถึงแล้วใน Apache Ignite Wiki: .
มักจะมีบันทึกทางกายภาพหลายรายการต่อบันทึกทางลอจิคัล ตัวอย่างเช่น นั่นคือ การดำเนินการหนึ่งที่ใส่ไว้ในแคชจะส่งผลต่อหลายเพจในหน่วยความจำเพจ (เพจที่มีข้อมูลเอง เพจที่มีดัชนี เพจที่มีรายการอิสระ) ในการทดสอบสังเคราะห์บางอย่าง ฉันพบว่าบันทึกทางกายภาพครอบครองถึง 90% ของไฟล์ WAL อย่างไรก็ตาม สิ่งเหล่านี้จำเป็นในช่วงเวลาสั้น ๆ (โดยค่าเริ่มต้น ช่วงเวลาระหว่างจุดตรวจคือ 3 นาที) คงจะสมเหตุสมผลที่จะกำจัดข้อมูลนี้หลังจากสูญเสียความเกี่ยวข้องไปแล้ว นี่คือสิ่งที่กลไกการบดอัด WAL ทำ: โดยจะกำจัดบันทึกทางกายภาพและบีบอัดบันทึกโลจิคัลที่เหลือโดยใช้ zip ในขณะที่ขนาดไฟล์จะลดลงอย่างมาก (บางครั้งหลายสิบครั้ง)
ตามจริงแล้ว WAL ประกอบด้วยหลายส่วน (10 ส่วนโดยค่าเริ่มต้น) ที่มีขนาดคงที่ (64MB โดยค่าเริ่มต้น) ซึ่งจะถูกเขียนทับในลักษณะวงกลม ทันทีที่เติมเซ็กเมนต์ปัจจุบัน เซ็กเมนต์ถัดไปจะถูกกำหนดให้เป็นปัจจุบัน และเซ็กเมนต์ที่เติมจะถูกคัดลอกไปยังไฟล์เก็บถาวรโดยเธรดแยกต่างหาก การบดอัด WAL ใช้งานได้กับส่วนเก็บถาวรแล้ว นอกจากนี้ ในฐานะเธรดแยกต่างหาก จะตรวจสอบการดำเนินการของจุดตรวจสอบ และเริ่มการบีบอัดในส่วนเก็บถาวรซึ่งไม่จำเป็นต้องใช้บันทึกทางกายภาพอีกต่อไป
ผลกระทบต่อประสิทธิภาพ
เนื่องจากการบดอัด WAL ทำงานเป็นเธรดที่แยกจากกัน จึงไม่ควรมีผลกระทบโดยตรงต่อการดำเนินการที่กำลังดำเนินการ แต่ยังคงเพิ่มภาระงานพื้นหลังเพิ่มเติมบน CPU (การบีบอัด) และดิสก์ (อ่านแต่ละส่วน WAL จากไฟล์เก็บถาวรและเขียนส่วนที่บีบอัด) ดังนั้นหากระบบทำงานที่ความจุสูงสุด ก็จะทำให้ประสิทธิภาพลดลงเช่นกัน
วิธีเปิดใช้งานและกำหนดค่า
คุณสามารถเปิดใช้งานการบดอัด WAL ได้โดยใช้คุณสมบัติ WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). นอกจากนี้ เมื่อใช้เมธอด DataStorageConfiguration.setWalCompactionLevel() คุณสามารถตั้งค่าระดับการบีบอัดได้ หากคุณไม่พอใจกับค่าเริ่มต้น (BEST_SPEED)
การบีบอัดสแนปช็อตหน้า WAL
Какэтоработает
เราได้พบแล้วว่าในบันทึก WAL แบ่งออกเป็นเชิงตรรกะและเชิงกายภาพ สำหรับการเปลี่ยนแปลงแต่ละหน้า แต่ละบันทึก WAL จะถูกสร้างขึ้นในหน่วยความจำเพจ นอกจากนี้ บันทึกทางกายภาพยังถูกแบ่งออกเป็น 2 ประเภทย่อย: บันทึกสแน็ปช็อตเพจและบันทึกเดลต้า ทุกครั้งที่เราเปลี่ยนแปลงบางสิ่งบนเพจและถ่ายโอนจากสถานะสะอาดไปเป็นสถานะสกปรก สำเนาทั้งหมดของเพจนี้จะถูกจัดเก็บไว้ใน WAL (บันทึกสแนปช็อตของเพจ) แม้ว่าเราจะเปลี่ยนเพียงหนึ่งไบต์ใน WAL แต่บันทึกก็จะใหญ่กว่าขนาดหน้าเล็กน้อย หากเราเปลี่ยนแปลงบางสิ่งในหน้าที่สกปรกอยู่แล้ว บันทึกเดลต้าจะถูกสร้างขึ้นใน WAL ซึ่งสะท้อนถึงการเปลี่ยนแปลงเท่านั้นเมื่อเปรียบเทียบกับสถานะก่อนหน้าของเพจ แต่ไม่ใช่ทั้งหน้า เนื่องจากการรีเซ็ตสถานะของเพจจากสกปรกเป็นล้างจะดำเนินการในระหว่างกระบวนการจุดตรวจสอบ ทันทีหลังจากเริ่มต้นจุดตรวจสอบ บันทึกทางกายภาพเกือบทั้งหมดจะประกอบด้วยเพียงสแนปชอตของหน้าเท่านั้น (เนื่องจากทุกหน้าทันทีหลังจากเริ่มต้นจุดตรวจสอบจะสะอาด) จากนั้นเมื่อเราเข้าใกล้จุดตรวจสอบถัดไป เศษส่วนบันทึกเดลต้าจะเริ่มขยายและรีเซ็ตอีกครั้งที่จุดเริ่มต้นของจุดตรวจสอบถัดไป การวัดในการทดสอบสังเคราะห์บางอย่างแสดงให้เห็นว่าส่วนแบ่งของสแน็ปช็อตหน้าในปริมาณบันทึกทางกายภาพทั้งหมดสูงถึง 90%
แนวคิดของการบีบอัดสแน็ปช็อตหน้า WAL คือการบีบอัดสแนปชอตของหน้าโดยใช้เครื่องมือบีบอัดหน้าสำเร็จรูป (ดูการบีบอัดหน้าดิสก์) ในเวลาเดียวกัน ใน WAL บันทึกจะถูกบันทึกตามลำดับในโหมดต่อท้ายเท่านั้น และไม่จำเป็นต้องผูกบันทึกกับขอบเขตของบล็อกระบบไฟล์ ดังนั้นที่นี่ ซึ่งแตกต่างจากกลไกการบีบอัดหน้าดิสก์ เราไม่ต้องการไฟล์กระจัดกระจายที่ ทั้งหมด ดังนั้นกลไกนี้จะใช้งานได้ไม่เพียงแต่บน OS Linux เท่านั้น นอกจากนี้ไม่สำคัญสำหรับเราอีกต่อไปว่าเราสามารถบีบอัดหน้าเว็บได้มากเพียงใด แม้ว่าเราจะเพิ่มพื้นที่ว่าง 1 ไบต์ แต่นี่ก็เป็นผลดีอยู่แล้ว และเราสามารถบันทึกข้อมูลที่บีบอัดใน WAL ได้ ซึ่งแตกต่างจากการบีบอัดหน้าดิสก์ โดยเราจะบันทึกหน้าที่บีบอัดเฉพาะเมื่อเราปล่อยบล็อกระบบไฟล์มากกว่า 1 บล็อกเท่านั้น
หน้าต่างๆ เป็นข้อมูลที่บีบอัดได้สูง ส่วนแบ่งในปริมาณ WAL ทั้งหมดนั้นสูงมาก ดังนั้นหากไม่มีการเปลี่ยนแปลงรูปแบบไฟล์ WAL เราจึงสามารถลดขนาดลงได้อย่างมาก การบีบอัด รวมถึงบันทึกทางลอจิคัล จะต้องมีการเปลี่ยนแปลงรูปแบบและสูญเสียความเข้ากันได้ เช่น สำหรับผู้ใช้ภายนอกที่อาจสนใจบันทึกทางลอจิคัล แต่จะไม่ทำให้ขนาดไฟล์ลดลงอย่างมาก
เช่นเดียวกับการบีบอัดดิสก์เพจ การบีบอัดสแน็ปช็อตเพจ WAL สามารถใช้อัลกอริธึมการบีบอัด ZSTD, LZ4, Snappy รวมถึงโหมด SKIP_GARBAGE
ผลกระทบต่อประสิทธิภาพ
สังเกตได้ไม่ยากว่าการเปิดใช้งานการบีบอัดสแน็ปช็อตเพจ WAL โดยตรงจะส่งผลต่อเธรดที่เขียนข้อมูลลงในหน่วยความจำเพจเท่านั้น นั่นคือเธรดที่เปลี่ยนแปลงข้อมูลในแคช การอ่านบันทึกทางกายภาพจาก WAL เกิดขึ้นเพียงครั้งเดียว ในขณะที่โหนดถูกยกขึ้นหลังจากการล้ม (และเฉพาะในกรณีที่โหนดตกลงระหว่างจุดตรวจ)
สิ่งนี้ส่งผลต่อเธรดที่เปลี่ยนแปลงข้อมูลในลักษณะต่อไปนี้: เราได้รับเอฟเฟกต์เชิงลบ (CPU) เนื่องจากจำเป็นต้องบีบอัดเพจในแต่ละครั้งก่อนที่จะเขียนลงดิสก์ และเอฟเฟกต์เชิงบวก (ดิสก์ IO) เนื่องจากการลดจำนวน ข้อมูลที่เขียน ดังนั้น ทุกอย่างจึงเป็นเรื่องง่าย: หากประสิทธิภาพของระบบถูกจำกัดโดย CPU เราจะได้ประสิทธิภาพลดลงเล็กน้อย หากถูกจำกัดโดย I/O ของดิสก์ เราก็จะได้รับค่าเพิ่มขึ้น
การลดขนาด WAL ทางอ้อมยังส่งผลต่อสตรีม (เชิงบวก) ที่ดัมพ์ส่วน WAL ลงในไฟล์เก็บถาวรและสตรีมการบดอัด WAL
การทดสอบประสิทธิภาพจริงในสภาพแวดล้อมของเราโดยใช้ข้อมูลสังเคราะห์พบว่าเพิ่มขึ้นเล็กน้อย (ปริมาณงานเพิ่มขึ้น 10%-15% เวลาแฝงลดลง 10%-15%)
วิธีเปิดใช้งานและกำหนดค่า
เวอร์ชันขั้นต่ำของ Apache Ignite: 2.8 เปิดใช้งานและกำหนดค่าดังนี้:
- จะต้องมีโมดูลการบีบอัดจุดชนวนในคลาสพาธ ตามค่าเริ่มต้น จะอยู่ในการกระจาย Apache Ignite ในไดเร็กทอรี libs/ทางเลือก และไม่รวมอยู่ในคลาสพาธ คุณสามารถย้ายไดเร็กทอรีขึ้นไปหนึ่งระดับไปที่ libs จากนั้นเมื่อคุณรันไดเร็กทอรีผ่าน ignite.sh ไดเร็กทอรีจะถูกเปิดใช้งานโดยอัตโนมัติ
- ต้องเปิดใช้งานความคงอยู่ (เปิดใช้งานผ่าน
DataRegionConfiguration.setPersistenceEnabled(true)). - ต้องตั้งค่าโหมดการบีบอัดโดยใช้วิธีการ
DataStorageConfiguration.setWalPageCompression()การบีบอัดจะถูกปิดใช้งานตามค่าเริ่มต้น (โหมด DISABLED) - หรือคุณสามารถตั้งค่าระดับการบีบอัดโดยใช้วิธีการได้
DataStorageConfiguration.setWalPageCompression()โปรดดู javadoc สำหรับวิธีการหาค่าที่ถูกต้องสำหรับแต่ละโหมด
ข้อสรุป
กลไกการบีบอัดข้อมูลที่พิจารณาใน Apache Ignite สามารถใช้แยกจากกันได้ แต่ก็ยอมรับการใช้กลไกการบีบอัดข้อมูลร่วมกันก็ได้ การทำความเข้าใจวิธีการทำงานจะช่วยให้คุณระบุได้ว่าสิ่งเหล่านี้เหมาะสมกับงานของคุณในสภาพแวดล้อมของคุณเพียงใด และคุณจะต้องเสียสละอะไรบ้างเมื่อใช้สิ่งเหล่านี้ การบีบอัดหน้าดิสก์ได้รับการออกแบบมาเพื่อบีบอัดที่เก็บข้อมูลหลักและสามารถให้อัตราส่วนการบีบอัดปานกลาง การบีบอัดสแนปช็อตเพจ WAL จะให้ระดับการบีบอัดโดยเฉลี่ยสำหรับไฟล์ WAL และมีแนวโน้มที่จะปรับปรุงประสิทธิภาพด้วยซ้ำ การบีบอัด WAL จะไม่ส่งผลดีต่อประสิทธิภาพการทำงาน แต่จะลดขนาดของไฟล์ WAL ให้มากที่สุดเท่าที่จะเป็นไปได้โดยการลบบันทึกทางกายภาพออก
ที่มา: will.com