Limbo - SQLite ที่ถูกเขียนขึ้นใหม่ทั้งหมดด้วย Rust

 (turso.tech)
17 คะแนน โดย GN⁺ 2024-12-11 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • Limbo เป็นโปรเจกต์เชิงทดลองที่นำ SQLite มาเขียนใหม่ด้วย Rust ซึ่งให้ความปลอดภัยด้านหน่วยความจำ
    • ชื่นชอบคุณสมบัติแบบ embedded ของ SQLite แต่ต้องการโมเดลการพัฒนาที่เปิดกว้างกว่า จึงเริ่มโปรเจกต์ libSQL
  • เหตุผลที่ fork SQLite: สามารถผสานฟีเจอร์ใหม่ได้ง่ายขึ้น และยังคงความเข้ากันได้กับโค้ดเดิม
    • ข้อเสีย: ชุดทดสอบของ SQLite เป็นกรรมสิทธิ์และเขียนด้วย C ทำให้พัฒนาโค้ดต่อได้ยาก
  • แนวทางใหม่
    • พบข้อจำกัดของ SQLite ระหว่างการเพิ่มความสามารถด้าน vector search
    • สำรวจความเป็นไปได้ในการเขียน SQLite ใหม่ตั้งแต่ต้น โดยยังรักษาความเข้ากันได้ไว้ พร้อมเปิดทางให้เพิ่มฟีเจอร์เชิงรุกมากขึ้น
  • ขั้นถัดไป
    • เปลี่ยน Limbo ให้เป็นโปรเจกต์อย่างเป็นทางการของ Turso
    • ตั้งเป้าสร้างสถาปัตยกรรมใหม่ที่ให้ความปลอดภัยด้านหน่วยความจำ พร้อมคงความน่าเชื่อถือระดับเดียวกับ SQLite
  • ท้าทายความน่าเชื่อถือของ SQLite
    • สร้างความน่าเชื่อถือสูงผ่านการทดสอบ deterministic simulation testing (DST)
    • ใช้เฟรมเวิร์กระดับระบบสำหรับ DST ร่วมกับ Antithesis
  • สถานะปัจจุบัน
    • I/O แบบ asynchronous เต็มรูปแบบ: Limbo ออกแบบให้เป็น asynchronous ทั้งระบบ เพื่อแก้ปัญหาอินเทอร์เฟซแบบ synchronous ของ SQLite
    • ออกแบบมาสำหรับ WASM: ออกแบบโดยคำนึงถึงการใช้งานในสภาพแวดล้อม WASM
    • ประสิทธิภาพ: ในหลายงานให้ประสิทธิภาพเทียบเท่าหรือเร็วกว่า SQLite
    • ความเรียบง่าย: ตัดฟีเจอร์ที่สำคัญน้อยลงในสภาพแวดล้อมสมัยใหม่ออก เพื่อมอบประสบการณ์ใช้งานที่ดีขึ้น
  • ข้อมูลเพิ่มเติม
    • Limbo เปิดให้ใช้งานบน GitHub ภายใต้ไลเซนส์ MIT
    • เชิญชวนผู้ที่สนใจสร้าง embedded database ที่ต้องการพาคำมั่นสัญญาของ SQLite ไปอีกขั้นมาร่วมกัน

บทความที่เกี่ยวข้อง

4 ความคิดเห็น

 
seonwoo960000 2024-12-21

รู้สึกแปลกดีนะครับที่โปรเจกต์ที่ผมเคยมีส่วนร่วมไปโผล่บน hacker news 555
 
GN⁺ 2024-12-11
ความคิดเห็นบน Hacker News

  • SQLite ดูเป็นโปรเจ็กต์ที่ไม่จำเป็นต้องเขียนใหม่ เนื่องจากคุณภาพโค้ดและการทดสอบที่เข้มงวด

    • มีความเห็นว่าอยากเห็นโค้ด C อื่นถูกเขียนใหม่ก่อน

  • การถกเถียงว่า SQLite ไม่ได้ "เปิดรับการมีส่วนร่วม" นั้นมองข้ามไปว่าการรับ contribution ไม่ได้หมายความว่าจะรับทุก contribution เสมอไป

    • SQLite มีกระบวนการสำหรับการมีส่วนร่วม และเป็นแนวทางให้ไปพัฒนาฟีเจอร์ที่เสนอไว้
    • โปรเจ็กต์อื่นใน ecosystem ของ SQLite อย่าง Litestream และ LiteFS ก็มีนโยบายการรับ contribution คล้ายกัน

  • เดิมทีมีมุมมองเชิงลบต่อการประกาศครั้งแรกของการ fork จาก SQLite3 ไปเป็น LibSQL

    • คิดว่ามีโอกาสสูงที่ fork จะล้มเหลว เพราะ test suite ของ SQLite3 เป็นกรรมสิทธิ์
    • แต่ก็มองว่าถ้ามีผลิตภัณฑ์ขนาดใหญ่ เช่น การเขียนใหม่ด้วยภาษาที่ปลอดภัยด้านหน่วยความจำ fork ก็มีความหมาย

  • หากต้องการประสิทธิภาพสูงสุด ควรเลือกโหมด WAL และควรปิดใช้งาน POSIX advisory locks

    • มีความเห็นสงสัยว่าโหมด wal2 อยู่ในเรดาร์ของโปรเจ็กต์หรือไม่

  • มีความเห็นว่าเพิ่งรู้เป็นครั้งแรกว่า test suite ของ SQLite เป็นกรรมสิทธิ์

    • Android ก็ถูกสร้างขึ้นในลักษณะคล้ายกัน แต่เป็นอีกประเด็นหนึ่ง

  • ไม่เห็นด้วยกับตรรกะในส่วน "async IO"

    • มองว่าไม่จำเป็นต้องเขียน SQLite ใหม่เพื่อเพิ่ม asynchronous interface
    • ปัญหาของ synchronous interface ใน SQLite คือ thread จะว่างอยู่ขณะรอ IO
    • SQLite ถูกออกแบบมาให้ทำงานใกล้กับ storage มาก จึงอาจมีการบล็อก IO ที่สั้นมากหรือแทบไม่มีเลย

  • มีความเห็นว่าเป็นโปรเจ็กต์ที่ยังอยู่ในระยะเริ่มต้น

    • มีการยกตัวอย่างโค้ดที่ใช้ Python และ Limbo

  • หากคอมไพล์ด้วย Fil-C ก็จะได้ SQLite ที่ปลอดภัยด้านหน่วยความจำ

    • ต้องแก้ไขเพียงเล็กน้อย และเกือบผ่าน test suite ทั้งหมด

  • SQLite ประกอบด้วยโค้ดประมาณ 156,000 บรรทัด และโค้ดทดสอบ 92,000 บรรทัด

  • คาดว่าไม่ได้มีการพิจารณาเรื่องการรับรอง DO-178B สำหรับเวอร์ชัน Rust

  • ชื่อ "Limbo" ยังถูกใช้ในภาษาหลัง C/UNIX สำหรับระบบปฏิบัติการ Inferno ของ AT&T ด้วย
 
aer0700 2024-12-12

SQLite ดูเป็นโปรเจกต์ที่ไม่จำเป็นต้องเขียนใหม่ เพราะคุณภาพโค้ดและการทดสอบที่เข้มงวด -> คำชื่นชมแบบนี้ต่อ sqlite น่าอิจฉาและยอดเยี่ยมจริง ๆ
 
regentag 2024-12-12

ระบุว่าปฏิบัติตามกระบวนการ DO-178B และบรรลุ MC/DC code coverage 100%
เรื่องเล่าที่ไม่ค่อยมีใครรู้ของ SQLite