- SQLite เป็นที่เก็บข้อมูลแบบแถวที่จัดเก็บลงดิสก์ด้วยโครงสร้าง B-tree และใช้เครื่องเสมือนชื่อ VDBE ในการรันคิวรี ทำงานได้แทบทุกสภาพแวดล้อมแบบเธรดเดียวโดยไม่ขึ้นกับแพลตฟอร์ม
- แม้จะเป็นฐานข้อมูลสำหรับงานทั่วไป แต่โดดเด่นมากกับงาน OLTP โดยในปี 2015 นักวิจัยจากมหาวิทยาลัยบัฟฟาโลพบว่าคิวรีส่วนใหญ่เป็นทั้งการค้นหา key-value แบบง่ายและคิวรี OLAP ที่ซับซ้อน
- นักวิจัยจากมหาวิทยาลัยวิสคอนซิน-แมดิสันพยายามทำให้คิวรีเชิงวิเคราะห์เร็วขึ้น และใช้ DuckDB กับ Star Schema Benchmark (SSB) เพื่อเปรียบเทียบประสิทธิภาพ
สาเหตุ
- เพื่อหาสาเหตุที่ SQLite ช้า จึงใช้ตัวเลือก
VDBE_PROFILE วัดจำนวน CPU cycle ที่แต่ละคำสั่งของ VDBE ใช้ไป
- พบว่า opcode สองตัวคือ
SeekRowID และ Column เป็นสาเหตุหลัก
การ join ฐานข้อมูล
- วิธีที่ฐานข้อมูลใช้ในการทำ join มีทั้ง nested loop join, hash join และ sort-merge join
- SQLite ใช้วิธีที่ง่ายที่สุดคือ "nested loop join" ซึ่งมีต้นทุนสูงเพราะคล้ายกับการค้นหาใน B-tree
ความสำคัญของการปรับแต่ง join
- ในการทำ join ลำดับของตารางมีความสำคัญมาก การสลับลำดับสามารถลดจำนวนการคำนวณได้อย่างมาก และเป็นปัญหาแบบ NP-hard
- มีอัลกอริทึม join ที่ดีกว่า nested loop join อยู่สองแบบ แต่ hash join ใช้หน่วยความจำมาก ขณะที่ SQLite มักทำงานในสภาพแวดล้อมที่มีข้อจำกัดด้านหน่วยความจำ
- ทีมวิจัยจึงใช้ Bloom filter เพื่อเพิ่มประสิทธิภาพด้านพื้นที่และให้พอดีกับ CPU cache line พร้อมเพิ่ม opcode สองตัวคือ
Filter และ FilterAdd
ผลลัพธ์
- หลังการปรับแต่ง จากการวิเคราะห์ CPU cycle แถบสีน้ำเงินขนาดใหญ่แทบหายไป
- SQLite เร็วขึ้น 7 ถึง 10 เท่า และผลงานวิจัยนี้ถูกนำเข้าไปใช้ใน SQLite v3.38.0
- Bloom filter เข้ากันได้ดีกับแนวทางการนำไปใช้ที่เรียบง่ายของ SQLite ทำงานภายใน query engine เดิม และมี memory overhead ต่ำมาก
3 ความคิดเห็น
พอตรวจดูเวอร์ชันตอนนี้แล้ว ระบบนี้ใช้ 3.42.0 อยู่ครับ ส่วนเวอร์ชันล่าสุด ณ ปัจจุบันคือ 3.47.2
คงต้องลองตรวจสอบเวอร์ชัน SQLite ที่ใช้อยู่ตอนนี้ดูแล้วครับ
จริง ๆ ตอนนี้ผมกำลังใช้ openpyxl เพื่อสร้างไฟล์ Excel อยู่ แต่ใช้เวลานานพอสมควร เลยคงต้องลองหาดูว่ามีไลบรารีอื่นไหมครับ
น่าจะลองทำโปรไฟล์ดูก่อนไม่ดีกว่าเหรอ