เหตุผลที่ SQLite ใช้ Bytecode

วิธีการทำงานทั่วไปของเอนจินฐานข้อมูล SQL

• เอนจินฐานข้อมูล SQL ทุกตัวทำงานในลักษณะคล้ายกัน
  • แปลงคำสั่ง SQL ที่ป้อนเข้าไปให้เป็น "prepared statement"
  • "รัน" prepared statement เพื่อสร้างผลลัพธ์
• ใน SQLite นั้น prepared statement ถูกแสดงในรูปของอินสแตนซ์ของอ็อบเจ็กต์ sqlite3_stmt
• วิธีการแสดง prepared statement โดยหลักมีอยู่ 2 แบบ
  • แบบ bytecode: ใช้ใน SQLite
  • แบบ object tree: ใช้ใน MySQL, PostgreSQL

ข้อดีของแนวทางแบบ bytecode

• เข้าใจได้ง่าย
  • ประกอบด้วยชุดคำสั่งแบบง่าย ๆ จึงพิมพ์แสดงผลได้สะดวก
  • หากใช้คีย์เวิร์ด EXPLAIN ก็สามารถดู bytecode ของคำสั่ง SQL ได้
• ดีบักได้ง่าย
  • แยกขั้นตอน parsing/analysis ออกจากขั้นตอน execution ได้อย่างชัดเจน
  • ในดีบักบิลด์สามารถติดตามการทำงานของ bytecode ได้ด้วยคำสั่ง PRAGMA vdbe_trace=ON
• ทำงานแบบ incremental ได้
  • คำสั่ง SQL ที่เขียนเป็น bytecode สามารถทำงานทีละแถว แล้วหยุดและกลับมาทำต่อได้
  • ส่วนแนวทาง object tree จะรันทั้ง tree พร้อมกัน จึงทำงานแบบ incremental ได้ยาก
• ใช้หน่วยความจำน้อย
  • bytecode มีขนาดเล็กกว่า AST
  • prepared statement มักถูกแคชค้างไว้ในหน่วยความจำเป็นเวลานาน ดังนั้นการใช้หน่วยความจำจึงสำคัญ
• ทำงานได้เร็ว
  • แต่ละขั้นมีสิ่งที่ต้องตัดสินใจน้อยกว่า จึงรันได้เร็ว

ข้อดีของแนวทางแบบ object tree

• ปรับเปลี่ยนแผนคิวรีขณะรันได้
  • object tree ปรับแก้ได้ง่ายแม้ระหว่างการทำงาน
  • จึงสามารถปรับแต่งให้เหมาะสมแบบไดนามิกตามความคืบหน้าของคิวรีได้
• ทำงานแบบขนานได้ง่าย
  • สามารถมอบหมายแต่ละ processing node ให้กับเธรดแยกได้
  • เพียงซิงก์การส่งข้อมูลระหว่าง node เท่านั้น
  • จึงได้เปรียบเมื่อต้องรันคิวรีวิเคราะห์ข้อมูลขนาดใหญ่ (OLAP) บนหลายคอร์

ความเห็นของ GN⁺

• เป้าหมายหลักของ SQLite คือการประมวลผลธุรกรรม (OLTP) ในสภาพแวดล้อม IoT ดังนั้นแนวทางแบบ bytecode จึงดูเหมาะสม เพราะเรียบง่าย เบา และให้ประสิทธิภาพที่รวดเร็ว
• ในทางกลับกัน MySQL และ PostgreSQL มักถูกใช้งานกับการวิเคราะห์ข้อมูลขนาดใหญ่ด้วยเช่นกัน ดังนั้นข้อดีของแนวทางแบบ object tree ที่สามารถปรับแผนการรันคิวรีแบบไดนามิกและทำงานขนานได้ จึงอาจโดดเด่นกว่า
• อย่างไรก็ตาม แนวทางแบบ object tree ก็มีข้อเสียคือดีบักหรือวิเคราะห์ประสิทธิภาพได้ยาก นอกจากนี้จากต้นทุนของการเดิน tree เป็นต้น ในกรณีของคิวรีง่าย ๆ ก็อาจช้ากว่า bytecode ได้เช่นกัน
• ประเด็นสำคัญคือการเลือกแนวทางที่เหมาะกับลักษณะการใช้งานและวัตถุประสงค์ สำหรับ RDBMS แบบใช้งานทั่วไป ก็อาจพิจารณาแนวทางไฮบริดที่ประนีประนอมข้อดีข้อเสียของทั้งสองแบบได้เช่นกัน

[GN⁺]

ความคิดเห็นจาก Hacker News

• การที่ SQLite ใช้ไบต์โค้ด virtual machine (VM) แทน abstract syntax tree (AST) สำหรับรัน SQL query เป็นทางเลือกด้านการออกแบบที่น่าสนใจสำหรับฐานข้อมูล ข้อดีของไบต์โค้ดเมื่อเทียบกับ AST มีดังนี้:

  • กะทัดรัดกว่า: ไบต์โค้ดกะทัดรัดกว่า AST เพราะไม่ต้องมี malloc/ส่วนหัวของอ็อบเจ็กต์และพอยน์เตอร์ที่ซ่อนอยู่สำหรับ subexpression
  • ประสิทธิภาพ: การรันไบต์โค้ดเร็วกว่า เพราะใช้แคชได้ดีกว่าและมี cache miss จากการไล่ตามพอยน์เตอร์น้อยกว่า
  • การรันแบบเพิ่มทีละส่วน: ด้วยการใช้สแตกแบบชัดเจน การหยุดและรันต่อโดยไม่ต้องคลายสแตกหลักทำได้ง่ายกว่าด้วยไบต์โค้ด

• ไบต์โค้ด VM และอินเทอร์พรีเตอร์มักถูกเชื่อมโยงกับภาษาการเขียนโปรแกรมแบบทั่วไป แต่ก็สามารถมีประโยชน์อย่างน่าประหลาดในบริบทอื่น ๆ เช่นกัน:

  • eBPF: กลไกการขยายความสามารถของ Linux kernel
  • DWARF expression language: ใช้ในดีบักเกอร์อย่าง GDB และ LLDB
  • RAR file format: มีการเข้ารหัสไบต์โค้ดสำหรับการแปลงข้อมูลแบบกำหนดเอง

• Microsoft SQL Server ภายในใช้ object tree แต่ผลลัพธ์ query plan ก็ยังแสดงออกมาในรูปแบบตาราง ซึ่งแสดงให้เห็นว่าการเรนเดอร์ object tree ให้เป็นตารางนั้นทำได้ยาก

• โปรแกรมเมอร์มักรู้แน่ชัดว่าการค้นหาดัชนีใดควรเกิดขึ้นภายในลูป ดังนั้นในบางกรณี การเขียนไบต์โค้ดโดยตรงหรือใช้ภาษาคำสั่งระดับสูงอาจได้เปรียบกว่าการใช้ SQL การแสดงสิ่งนี้ด้วย SQL อาจเป็นภาระได้

• หากคอขวดไม่ได้อยู่ที่การรันไบต์โค้ด (เช่น อยู่ที่ความเร็วหน่วยความจำหรือดิสก์) ก็อาจไม่จำเป็นต้องแปลงเป็น native code ผ่าน JIT compilation

• ภาษาการเขียนโปรแกรมจำนวนมาก เช่น Python, Ruby และ Lua ใช้ไบต์โค้ดหรือ AST ภายในอยู่แล้ว และเนื่องจากการตัดสินใจด้านการออกแบบฐานข้อมูล จึงอาจมีประโยชน์ที่จะมีคำสั่งที่พาร์สได้ง่ายสำหรับไลบรารีภายนอกหรือการทำ ORM ที่มีโอกาสเกิดข้อผิดพลาดได้ง่าย