ตามหา SQLite ที่เร็วกว่าเดิม

 (avi.im)
2 คะแนน โดย GN⁺ 2024-12-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SQLite เป็นระบบฐานข้อมูลที่เร็วอยู่แล้ว แต่นักวิจัยกำลังมองหาวิธีทำให้มันเร็วขึ้นไปอีก
  • นักวิจัยจากมหาวิทยาลัยเฮลซิงกิและเคมบริดจ์เผยแพร่บทความวิจัยชื่อ "การออกแบบร่วมกันระหว่างรันไทม์/ฐานข้อมูลแบบ serverless ผ่าน asynchronous I/O" โดยแสดงให้เห็นว่าสามารถลด tail latency ได้สูงสุดถึง 100 เท่า บทความนี้กลายมาเป็นรากฐานของ Limbo ซึ่งเป็น SQLite ที่ถูกเขียนใหม่ด้วย Rust

io_uring

  • คำอธิบาย io_uring: ซับซิสเต็ม io_uring ของ Linux kernel มอบอินเทอร์เฟซสำหรับ asynchronous I/O โดยลดโอเวอร์เฮดจากการคัดลอกบัฟเฟอร์ผ่าน ring buffer ระหว่าง user space และ kernel space แอปพลิเคชันสามารถส่งคำขอ I/O แล้วไปทำงานอื่นต่อได้จนกว่า OS จะแจ้งว่างาน I/O เสร็จสิ้น

  • การประมวลผลคิวรีของ SQLite: SQLite ใช้ไฟล์ในการเก็บข้อมูล เปิดฐานข้อมูลด้วยฟังก์ชัน sqlite3_open() และแปลงคำสั่ง SQL ให้เป็น bytecode ด้วยฟังก์ชัน sqlite3_prepare() จากนั้นฟังก์ชัน sqlite3_step() จะรันคำสั่ง bytecode เพื่อประมวลผลคิวรี

ข้อสมมติฐาน

  • การเติบโตของ serverless computing: ในสภาพแวดล้อมแบบ serverless ความหน่วงของฐานข้อมูลอาจกลายเป็นปัญหาได้ หากฝังฐานข้อมูลไว้ใน edge runtime โดยตรงก็จะไม่มีความหน่วงจากเครือข่าย และ SQLite ก็เหมาะกับสภาพแวดล้อมลักษณะนี้

  • ปัญหาของ SQLite: การใช้ synchronous I/O ทำให้การใช้ทรัพยากรไม่เหมาะสมที่สุด และก่อให้เกิดปัญหาเรื่อง concurrency และ multi-tenancy

  • การเปลี่ยนไปใช้ io_uring: การแทนที่การเรียก POSIX I/O ด้วย io_uring ไม่ใช่เรื่องง่าย และต้องออกแบบ SQLite ใหม่ให้สอดคล้องกับโมเดล asynchronous I/O

Limbo

  • รองรับ asynchronous I/O: มีการปรับแก้ส่วนประกอบ VM และ BTree เพื่อรองรับ asynchronous I/O และแทนที่คำสั่ง bytecode แบบ synchronous ด้วยคำสั่งแบบ asynchronous โดย asynchronous I/O ช่วยขจัดการบล็อกและเพิ่ม concurrency

  • แยก query engine กับ storage engine ออกจากกัน: มีข้อเสนอให้แยก query engine และ storage engine ออกจากกันเพื่อใช้ทรัพยากรให้ได้สูงสุด

การประเมินและผลลัพธ์

  • การทำเบนช์มาร์ก: มีการจำลองรันไทม์ serverless แบบ multi-tenant เพื่อให้แต่ละ tenant มีฐานข้อมูลแบบฝังตัวของตัวเอง เมื่อเปรียบเทียบความหน่วงของคิวรีระหว่าง SQLite กับ Limbo พบว่า Limbo ลด tail latency ที่ระดับ p999 ได้ถึง 100 เท่า

  • งานในอนาคต: มีแผนทำเบนช์มาร์กเพิ่มเติมที่รวมทั้งผู้อ่านและผู้เขียนหลายราย และข้อได้เปรียบด้านประสิทธิภาพจะเด่นชัดเป็นพิเศษหลังระดับ p999 เท่านั้น

  • โค้ดโอเพนซอร์ส: โค้ดของ Limbo เปิดเป็นโอเพนซอร์สแล้ว: Limbo GitHub

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

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

 
GN⁺ 2024-12-17
ความคิดเห็นจาก Hacker News

  • มีการพูดคุยว่าการประมวลผลแบบ serverless ในบางกรณีการใช้งาน เช่น AWS Lambda ไม่ได้เข้ากันได้ดีกับแอปที่มีฐานข้อมูลส่วนกลางซึ่งจัดในรูปแบบ serverless เสมอไป

    • มีประสบการณ์เคยทำงานเพื่อแก้ปัญหาเมื่อ 6-7 ปีก่อน ซึ่งต้องประมวลผลไฟล์แบบลำดับชั้นที่ซับซ้อนและดึงข้อมูลบางอย่างออกมา
    • FaaS มีค่าใช้จ่ายสูงสำหรับงานที่ใช้การคำนวณหนัก และการโหลดไฟล์ XML ขนาดใหญ่แล้ว parse ใหม่ทุกครั้งก็ไม่มีประสิทธิภาพ
    • วิธีแก้คือใช้ฟังก์ชันส่วนกลางที่ทำงานด้วยตัวจับเวลา อ่านและ parse ไฟล์ จากนั้นโหลดเข้า SQLite database และสร้างดัชนี ก่อนจะเก็บไฟล์ไว้ใน S3
    • ฟังก์ชัน Lambda จะดาวน์โหลดไฟล์จาก S3 แล้วทำการค้นหาเมื่อไฟล์ใหม่กว่าสำเนาในเครื่อง หรือเมื่อเกิด cold start
    • พบว่า Lambda มีไดเรกทอรี /tmp ในเครื่อง และ Python runtime ก็มี SQLite รวมมาให้แล้ว จึงไม่จำเป็นต้องอัปโหลดโค้ดเพิ่มเติมนอกเหนือจากตัวฟังก์ชัน
    • รู้สึกสนใจที่มีงานกำลังทำอยู่เพื่อทำให้โซลูชันแบบนี้เร็วขึ้นได้อีก

  • อาจควรระบุให้ชัดว่าในบรรดานักวิจัยสองคนนั้น มีหนึ่งคนเป็นหัวหน้าของผู้เขียน

    • ตอนแรกเข้าใจผิดว่าผู้เขียนกับนักวิจัยไม่ได้เกี่ยวข้องกัน

  • เห็นด้วยกับประเด็นที่ว่า "ข้อได้เปรียบจะเห็นชัดจริง ๆ เฉพาะที่ p999 ขึ้นไป ส่วนที่ p90 และ p99 ประสิทธิภาพแทบไม่ต่างจาก SQLite"

    • ชอบ SQLite และชอบการปรับแต่งประสิทธิภาพ แต่ประเด็นนี้เป็นความจริง

  • SQLite มีชุดทดสอบที่ครอบคลุมมาก จึงได้รับการทดสอบอย่างละเอียด

    • จึงสงสัยว่าการเขียนใหม่จะได้รับการทดสอบในระดับใกล้เคียงกันหรือไม่ โดยเฉพาะเมื่อใช้ความสามารถอย่าง io_uring ที่แม้จะเร็ว แต่เขียนยากและอาจมีบั๊กได้

  • สำหรับการทำ benchmark มีการจำลอง serverless runtime แบบ multi-tenant ที่แต่ละ tenant มี embedded database ของตัวเอง

    • SQLite มีเธรดของตัวเองต่อ tenant และวัดผลโดยรัน query ในแต่ละเธรด
    • มีข้อสงสัยว่าการตั้งค่า serverless SQLite จะใช้ SQLite process แยกต่อหนึ่งคำขอหรือไม่

  • ก่อนหน้านี้เคยมีความพยายามนำ asynchronous I/O มาใช้กับ Postgres แต่ถูกยกเลิกไป

    • ข้อเสนอล่าสุดคือเปิดให้สามารถแทนที่ storage manager ด้วยของที่ปรับแต่งเองได้ โดยไม่ต้อง fork codebase
    • สนใจข้อเสนอใหม่นี้มาก และมันเกี่ยวข้องกับแนวโน้มในการแยก storage ออกจาก compute

  • มีคำถามเกี่ยวกับแนวคิดที่ว่าระหว่างที่ asynchronous I/O ทำงานอยู่จะไปทำงานอื่นต่อได้

    • สงสัยว่าเวลาทำงานกับฐานข้อมูล ยังต้องรอให้ธุรกรรมเสร็จสิ้นก่อนหรือไม่

  • ในฐานะผู้เขียนบล็อกโพสต์ ไม่ได้คาดคิดว่าบทความนี้จะขึ้นหน้าแรก

    • ทำงานอยู่ที่ Turso และงานวิจัยนี้เผยแพร่เมื่อเดือนเมษายน 2024 หลังจากนั้นก็มีการปรับปรุงอีกมาก

  • SQLite เป็นโอเพนซอร์ส แต่ test harness สำคัญไม่ได้เป็นโอเพนซอร์ส

    • จึงมีคำถามว่าทางเลือกอื่นจะรับประกันความเข้ากันได้อย่างไร

  • เคยพยายามหาวิธีง่าย ๆ ในการสร้างฟอร์แมตคล้าย JSON จาก strict subset ของ SQLite file format แต่ไม่สำเร็จ

    • รูปแบบไฟล์มีความตามอำเภอใจอยู่มากจนหมดความสนใจไป แม้คนอื่นอาจทำสำเร็จก็ได้