แนวทางเชิงทดลองของนักพัฒนาในการสร้างฐานข้อมูลประสิทธิภาพสูงโดยใช้ io_uring ของ Linux และระบบ write-ahead log (WAL) แบบคู่ได้จุดประกายการถกเถียงทางเทคนิคอย่างรุนแรงในชุมชนโปรแกรมเมอร์ ความขัดแย้งมีจุดศูนย์กลางอยู่ที่ว่าการออกแบบที่เสนอนั้นยังคงรักษาการรับประกันความคงทนที่ฐานข้อมูลคาดหวังไว้หรือไม่
นักพัฒนาได้สร้างฐานข้อมูล key-value เชิงทดลองที่เรียกว่า Poro โดยใช้สิ่งที่พวกเขาเรียกว่าการออกแบบ dual WAL เพื่อให้ได้ประสิทธิภาพที่ดีขึ้นด้วยการดำเนินการ I/O แบบอะซิงโครนัส แทนที่จะใช้แนวทางแบบดั้งเดิมที่เขียนการเปลี่ยนแปลงลงดิสก์และรอการยืนยันก่อนตอบกลับไปยังไคลเอนต์ ระบบนี้ใช้ log แยกสองส่วน: intent WAL ที่บันทึกการดำเนินการที่วางแผนไว้ และ completion WAL ที่ยืนยันการดำเนินการที่สำเร็จ
องค์ประกอบทางเทคนิคหลัก
- Intent WAL: บันทึกการดำเนินการที่วางแผนไว้ก่อนการประมวลผล
- Completion WAL: บันทึกการดำเนินการที่เสร็จสิ้นเรียบร้อยแล้ว
- io_uring: อินเทอร์เฟซ async I/O ของ Linux ที่มีคิวสำหรับการส่งและการเสร็จสิ้น
- Circular Buffers: รวมกลุ่มรายการเพื่อปรับปรุงประสิทธิภาพ (เกณฑ์ความจุ 75%)
- Checksum Verification: การตรวจสอบความสมบูรณ์ของข้อมูลระหว่างการกู้คืน
- Separate Ring Buffers: ป้องกันการบล็อกแบบ head-of-line ระหว่าง WAL ประเภทต่างๆ
ชุมชนตั้งคำถามหลักการพื้นฐานของฐานข้อมูล
ชุมชนทางเทคนิคได้แสดงความกังวลอย่างจริงจังเกี่ยวกับการออกแบบพื้นฐาน นักพัฒนาหลายคนได้ชี้ให้เห็นสิ่งที่ดูเหมือนจะเป็นข้อบกพร่องที่สำคัญในแนวทางนี้ ระบบจะส่งคืนความสำเร็จให้กับไคลเอนต์หลังจากเขียนทั้ง intent และ completion records แบบอะซิงโครนัส แต่ก่อนที่จะมั่นใจว่าบันทึกเหล่านี้ถูกบันทึกลงดิสก์จริง ๆ นี่หมายความว่าไคลเอนต์อาจได้รับการยืนยันว่าข้อมูลของพวกเขาถูกบันทึกแล้ว แต่กลับสูญเสียข้อมูลนั้นหากระบบขัดข้องทันทีหลังจากนั้น
นี่หมายความว่าไคลเอนต์อาจได้รับความสำเร็จสำหรับคำขอ ซึ่งหากระบบขัดข้องทันทีหลังจากนั้น เมื่อเล่นซ้ำแล้ว อาจไม่มีคำขอนั้นถูกบันทึกไว้หรือไม่? นี่ไม่ละเมิด ACID หรือ?
คุณสมบัติ ACID (Atomicity, Consistency, Isolation, Durability) เป็นข้อกำหนดพื้นฐานสำหรับระบบฐานข้อมูลที่เชื่อถือได้ ด้าน durability โดยเฉพาะต้องการให้เมื่อธุรกรรมได้รับการยืนยันว่าสำเร็จแล้ว ข้อมูลต้องอยู่รอดจากความล้มเหลวของระบบ นักวิจารณ์โต้แย้งว่าแนวทาง dual WAL ทำลายการรับประกันนี้โดยพื้นฐาน
การอ้างสิทธิ์เรื่องประสิทธิภาพถูกตรวจสอบอย่างละเอียด
แม้ว่านักพัฒนาจะรายงานการปรับปรุงประสิทธิภาพที่น่าประทับใจ - อ้างว่าเพิ่มปริมาณงานธุรกรรมขึ้น 10 เท่า - สมาชิกชุมชนตั้งคำถามว่าผลประโยชน์เหล่านี้มาพร้อมกับต้นทุนของความน่าเชื่อถือของข้อมูลหรือไม่ นักพัฒนาที่มีประสบการณ์หลายคนได้แสดงความสับสนเกี่ยวกับว่าการดำเนินการเขียนแบบอะซิงโครนัสสองครั้งจะเร็วกว่าหรือเชื่อถือได้มากกว่าการเขียนแบบซิงโครนัสครั้งเดียวที่รับประกันการคงอยู่ของข้อมูลจริง ๆ ได้อย่างไร
การถกเถียงยังได้เน้นแนวทางทางเลือกที่ใช้ในระบบการผลิต นักพัฒนาบางคนได้แบ่งปันเทคนิคป้องกันการขัดข้องของตนเอง เช่น การใช้ไฟล์ hash และ length แยกต่างหากด้วยการดำเนินการ atomic rename หรือการใช้โครงสร้าง B-tree แบบ append-only ที่รวม WAL และการจัดเก็บข้อมูลเข้าด้วยกัน
แนวทาง WAL แบบดั้งเดิม เทียบกับ แนวทาง Dual WAL
| แง่มุม | WAL แบบดั้งเดิม | Dual WAL (ที่เสนอ) |
|---|---|---|
| การดำเนินการเขียน | การเขียนแบบซิงโครนัสครั้งเดียว | การเขียนแบบอะซิงโครนัสสองครั้ง (intent + completion) |
| การตอบสนองไคลเอนต์ | หลังจากได้รับการยืนยันการ flush ลงดิสก์ | หลังจากการดำเนินการในหน่วยความจำเสร็จสิ้น |
| การรับประกันความคงทน | แข็งแกร่ง (ข้อมูลรอดจากการขัดข้อง) | น่าสงสัย (ข้อมูลอาจสูญหาย) |
| การอ้างสิทธิ์ด้านประสิทธิภาพ | พื้นฐาน | รายงานการปรับปรุง 10 เท่า |
| กระบวนการกู้คืน | ใช้รายการที่ committed ทั้งหมด | ใช้เฉพาะรายการที่มีทั้งบันทึก intent และ completion |
รายละเอียดการใช้งานที่ขาดหายไปเป็นเชื้อเพลิงของความสับสน
การวิจารณ์จากชุมชนส่วนใหญ่เกิดจากคำอธิบายที่ไม่ชัดเจนในข้อเสนอเดิม นักพัฒนาบางคนสงสัยว่าการใช้งานจริงอาจรวมขั้นตอนที่ขาดหายไปซึ่งระบบรอให้บันทึก WAL ทั้งสองถูก flush ลงดิสก์ก่อนส่งคืนความสำเร็จให้กับไคลเอนต์ อย่างไรก็ตาม สิ่งนี้จะขจัดประโยชน์ด้านประสิทธิภาพที่อ้างไว้ เนื่องจากการรอการดำเนินการดิสก์สองครั้งน่าจะช้ากว่าการรอหนึ่งครั้ง
การอภิปรายยังได้ตั้งคำถามเกี่ยวกับสถานการณ์การเข้าถึงพร้อมกัน หาก thread หลายตัวกำลังเข้าถึงข้อมูลที่กำลังถูกเขียนแบบอะซิงโครนัส ระบบอาจเผชิญกับความท้าทายด้านความสอดคล้องเพิ่มเติมนอกเหนือจากความกังวลด้านความคงทนพื้นฐาน
ผลกระทบที่กว้างขึ้นสำหรับการออกแบบฐานข้อมูล
แม้จะมีการวิจารณ์ การทดลองนี้ได้จุดประกายการอภิปรายที่มีค่าเกี่ยวกับสถาปัตยกรรมฐานข้อมูลสมัยใหม่และศักยภาพของ io_uring สำหรับระบบจัดเก็บข้อมูลประสิทธิภาพสูง อินเทอร์เฟซ io_uring ของ Linux ให้ข้อได้เปรียบที่แท้จริงสำหรับแอปพลิเคชันที่สามารถใช้ประโยชน์จาก asynchronous I/O ได้อย่างเหมาะสม แต่ชุมชนฐานข้อมูลดูเหมือนจะสงสัยว่าประโยชน์เหล่านี้สามารถรับรู้ได้โดยไม่สูญเสียการรับประกันความน่าเชื่อถือพื้นฐาน
การถกเถียงยังคงดำเนินต่อไปในขณะที่นักพัฒนาแสวงหาความชัดเจนเกี่ยวกับรายละเอียดการใช้งานจริงและว่าระบบที่เสนอสามารถรักษาการปฏิบัติตาม ACID ได้อย่างแท้จริงในขณะที่ส่งมอบการปรับปรุงประสิทธิภาพที่สัญญาไว้
Write-ahead log (WAL): เทคนิคที่การเปลี่ยนแปลงถูกเขียนลงในไฟล์ log ก่อนที่จะถูกนำไปใช้กับฐานข้อมูลหลัก เพื่อให้มั่นใจว่าข้อมูลสามารถกู้คืนได้หลังจากขัดข้องio_uring: อินเทอร์เฟซ Linux kernel ที่ให้การดำเนินการ I/O แบบอะซิงโครนัสที่มีประสิทธิภาพ ช่วยให้แอปพลิเคชันส่งการดำเนินการหลายอย่างโดยไม่ต้องบล็อก
*ACID: ชุดคุณสมบัติ (Atomicity, Consistency, Isolation, Durability) ที่รับประกันธุรกรรมฐานข้อมูลที่เชื่อถือได้
อ้างอิง: Async I/O on Linux and durability