Turso โปรเจกต์ที่ทะเยอทะยานในการเขียน SQLite ใหม่ตั้งแต่เริ่มต้นด้วยภาษา Rust เพิ่งประสบปัญหาการเสียหายของข้อมูลที่น่าสับสน ซึ่งจุดประกายการถกเถียงอย่างรุนแรงในชุมชนนักพัฒนา ข้อผิดพลาดนี้ปรากฏขึ้นทุกครั้งที่ฐานข้อมูลมีขนาดเกิน 1GB ทำให้เกิดการตรวจสอบความสมบูรณ์ที่ล้มเหลวใน SQLite ตัวเดิม สิ่งที่ดูเหมือนจะเป็นข้อบกพร่องร้ายแรงในการเขียนใหม่ของพวกเขา กลับกลายเป็นฟีเจอร์ที่มีเอกสารบันทึกของ SQLite ที่ทีมงานมองข้ามไป
ภาพรวมโปรเจค Turso :
- ภาษา: เขียน SQLite ใหม่ด้วยภาษา Rust
- สถานะ: อยู่ในช่วงทดสอบแอลฟ่า
- ฟีเจอร์ใหม่: CDC, การเขียนพร้อมกัน, การเข้ารหัส
- การทดสอบ: ใช้ Deterministic Simulation Testing (DST)
- โมเดลธุรกิจ: โอเพนซอร์สพร้อมบริการคลาวด์เชิงพาณิชย์
ปริศนาของการเสียหายข้อมูลที่ 1GB
ปัญหานี้เกิดขึ้นครั้งแรกเมื่อวิศวกร Turso ค้นพบว่าฐานข้อมูลใดๆ ที่มีขนาดเกิน 1GB จะทำให้เกิดคำเตือนการเสียหายในการตรวจสอบความสมบูรณ์ของ SQLite จังหวะเวลานั้นแม่นยำมาก - ไม่ใช่ประมาณ 1GB แต่เป็นที่เกณฑ์ 1GB พอดี ไม่ว่าข้อมูลจะมาจาก blob ขนาดใหญ่ชิ้นเดียวหรือการแทรกข้อมูลเล็กๆ หลายพันครั้งก็ไม่สำคัญ ความสม่ำเสมอนี้ทำให้ข้อผิดพลาดนั้นทั้งคาดเดาได้และน่าสับสน
วิธีการทดสอบที่ซับซ้อนของทีม ซึ่งอาศัย Deterministic Simulation Testing เป็นหลัก ไม่สามารถตรวจพบปัญหานี้ได้เลย การทดสอบ fault injection ของพวกเขา ซึ่งออกแบบมาเพื่อจำลองความล้มเหลวในโลกจริง ป้องกันไม่ให้ฐานข้อมูลเติบโตใหญ่พอที่จะถึงจุด 1GB เมื่อพวกเขาเพิ่มการทดสอบที่ไม่มีการจำลองความผิดพลาดเข้าไป รูปแบบนี้จึงปรากฏชัดเจน
การวิพากษ์วิจารณ์จากชุมชนเกี่ยวกับการวิจัยพื้นฐาน
การตอบสนองของชุมชนนักพัฒนามาอย่างรวดเร็วและเป็นการวิพากษ์วิจารณ์ หลายคนตั้งคำถามว่าทีมที่อ้างว่าสร้างระบบที่เข้ากันได้จะมองข้ามแง่มุมพื้นฐานของสถาปัตยกรรม SQLite ได้อย่างไร การวิพากษ์วิจารณ์มุ่งเน้นไปที่สิ่งที่หลายคนมองว่าเป็นความล้มเหลวในการทำวิจัยพื้นฐานก่อนที่จะพยายามเขียนใหม่ที่ทะเยอทะยานเช่นนี้
How the fuck did you manage to write a clone of SQLite without reading the description of its file format?
Lock-byte page ที่จุด 1GB ไม่ใช่ความรู้ที่ซ่อนเร้น - มีการบันทึกไว้อย่างชัดเจนในเอกสารรูปแบบไฟล์อย่างเป็นทางการของ SQLite และมีมานานกว่าทศวรรษแล้ว ฟีเจอร์นี้มีอยู่เพื่อจัดการกลไกการล็อกไฟล์ แต่การใช้งานของ Turso ไม่ได้คำนึงถึงสิ่งนี้ ทำให้เกิดปัญหาความเข้ากันได้
 |
|---|
| การสนทนาดิจิทัลระหว่างนักพัฒนาที่อภิปรายปัญหาเกี่ยวกับการดีบั๊กฐานข้อมูลและการตรวจสอบความสมบูรณ์ |
ปัญหาที่แท้จริงเบื้องหลังข้อผิดพลาด
สาเหตุหลักไม่ใช่การเสียหายของข้อมูลในฐานข้อมูลของ Turso จริงๆ การตรวจสอบความสมบูรณ์ของพวกเขาเองแสดงว่าฐานข้อมูลนั้นสมบูรณ์ดี ปัญหาคือ SQLite คาดหวัง pending byte เฉพาะที่จุด 1GB สำหรับกลไกการล็อก หากไม่มีการใช้งานฟีเจอร์นี้อย่างเหมาะสม SQLite จะตีความฐานข้อมูลว่าเสียหาย แม้ว่าข้อมูลเองจะยังคงสมบูรณ์
การเปิดเผยนี้เน้นย้ำถึงความกังวลที่กว้างขึ้นในชุมชนเกี่ยวกับความท้าทายในการสร้างระบบที่เข้ากันได้อย่างแท้จริง เมื่อซอฟต์แวร์ต้นฉบับมีพฤติกรรมและกรณีพิเศษที่สะสมมาหลายทศวรรษ แม้แต่ฟีเจอร์ที่มีเอกสารบันทึกดีก็สามารถถูกมองข้ามได้ง่ายๆ ระหว่างความพยายามในการใช้งานใหม่
รายละเอียดของ SQLite Lock-Byte Page:
- ตำแหน่ง: อยู่ที่จุดหมาย 1GB ในไฟล์ฐานข้อมูล
- วัตถุประสงค์: กลไกการล็อกไฟล์สำหรับการเข้าถึงแบบพร้อมกัน
- เอกสาร: มีให้ในข้อกำหนดรูปแบบไฟล์อย่างเป็นทางการของ SQLite
- ผลกระทบ: จำเป็นสำหรับความเข้ากันได้กับ SQLite หากหายไปจะทำให้การตรวจสอบความสมบูรณ์ล้มเหลว
บทเรียนสำหรับความเข้ากันได้ของฐานข้อมูล
เหตุการณ์นี้ทำให้เกิดคำถามสำคัญเกี่ยวกับแนวทางในการเขียนระบบที่มีอยู่แล้วใหม่ แม้ว่าเป้าหมายของ Turso ในการเพิ่มฟีเจอร์อย่าง CDC (Change Data Capture) การเขียนแบบพร้อมกัน และการเข้ารหัสจะมีคุณค่า แต่การถกเถียงในชุมชนแสดงให้เห็นว่าการทบทวนเอกสารอย่างละเอียดควรมาก่อนความพยายามในการใช้งาน
การแก้ไขเองนั้นตรงไปตรงมาเมื่อระบุปัญหาได้แล้ว - การใช้งานกลไก lock-byte page ที่ SQLite คาดหวัง อย่างไรก็ตาม กระบวนการค้นพบเผยให้เห็นช่องว่างในวิธีการทดสอบและแนวปฏิบัติการวิจัยที่อาจส่งผลต่อแง่มุมความเข้ากันได้อื่นๆ ของโปรเจกต์
หมายเหตุ: CDC (Change Data Capture) เป็นเทคนิคสำหรับติดตามการเปลี่ยนแปลงในฐานข้อมูลเพื่อให้แอปพลิเคชันสามารถตอบสนองต่อการเปลี่ยนแปลงเหล่านั้นแบบเรียลไทม์