Mengapa SQLite Menggunakan Bytecode

Cara kerja umum mesin basis data SQL

• Semua mesin basis data SQL bekerja dengan cara yang mirip
  • Mengubah pernyataan SQL yang dimasukkan menjadi "prepared statement"
  • "Menjalankan" prepared statement untuk menghasilkan hasil
• Di SQLite, prepared statement direpresentasikan sebagai instance dari objek sqlite3_stmt
• Ada dua cara utama untuk merepresentasikan prepared statement
  • Pendekatan bytecode: digunakan di SQLite
  • Pendekatan pohon objek: digunakan di MySQL dan PostgreSQL

Kelebihan pendekatan bytecode

• Mudah dipahami
  • Terdiri dari deretan instruksi sederhana sehingga mudah ditampilkan
  • Dengan menggunakan kata kunci EXPLAIN, kita bisa melihat bytecode dari pernyataan SQL
• Mudah untuk debugging
  • Tahap parsing/analisis dan tahap eksekusi dipisahkan dengan jelas
  • Pada build debugging, eksekusi bytecode bisa dilacak dengan perintah PRAGMA vdbe_trace=ON
• Dapat dijalankan secara inkremental
  • Pernyataan SQL yang ditulis sebagai bytecode bisa dijalankan satu baris demi satu baris, lalu dihentikan dan dilanjutkan kembali
  • Pendekatan pohon objek mengeksekusi seluruh pohon sekaligus sehingga eksekusi inkremental sulit dilakukan
• Penggunaan memori rendah
  • Bytecode berukuran lebih kecil daripada AST
  • Prepared statement sering di-cache lama di memori, sehingga penggunaan memori menjadi penting
• Kecepatan eksekusi tinggi
  • Ada lebih sedikit hal yang harus diputuskan pada setiap tahap sehingga eksekusi lebih cepat

Kelebihan pendekatan pohon objek

• Dapat memodifikasi rencana kueri saat runtime
  • Pohon objek mudah diubah bahkan saat eksekusi berlangsung
  • Optimasi dinamis dimungkinkan sesuai progres kueri
• Mudah diparalelkan
  • Setiap node pemrosesan dapat dialokasikan ke thread terpisah
  • Yang perlu disinkronkan hanya pengiriman data antar node
  • Menguntungkan saat menjalankan kueri analitik skala besar (OLAP) di banyak core

Pendapat GN⁺

• Karena tujuan utama SQLite adalah pemrosesan transaksi (OLTP) di lingkungan Internet of Things, pendekatan bytecode tampak cocok. Alasannya, pendekatan ini sederhana, ringan, dan tetap mampu memberikan performa cepat.
• Sebaliknya, MySQL atau PostgreSQL juga banyak digunakan untuk analisis data skala besar, sehingga keunggulan pendekatan pohon objek yang dapat mengoptimalkan rencana eksekusi kueri secara dinamis dan mendukung paralelisasi bisa lebih menonjol.
• Namun, pendekatan pohon objek juga memiliki kelemahan, seperti debugging atau analisis performa yang lebih sulit. Selain itu, karena ada biaya traversal pohon dan sebagainya, untuk kueri sederhana pendekatan ini justru bisa lebih lambat daripada bytecode.
• Poin pentingnya adalah memilih pendekatan yang tepat sesuai kebutuhan dan tujuan. Untuk RDBMS serbaguna, pendekatan hibrida yang mengombinasikan kelebihan dan kekurangan kedua metode juga layak dipertimbangkan.

[GN⁺]

Komentar Hacker News

• Fakta bahwa SQLite menggunakan mesin virtual (VM) bytecode alih-alih abstract syntax tree (AST) untuk mengeksekusi kueri SQL adalah pilihan desain yang menarik untuk sebuah basis data. Keunggulan bytecode dibanding AST adalah sebagai berikut:

  • Ringkas: Bytecode lebih ringkas daripada AST karena tidak memerlukan malloc/header objek tersembunyi dan pointer untuk subekspresi.
  • Kinerja: Eksekusi bytecode lebih cepat karena pemanfaatan cache lebih baik dan cache miss akibat pointer chasing lebih sedikit.
  • Eksekusi inkremental: Dengan menggunakan stack eksplisit, lebih mudah untuk menjeda dan melanjutkan eksekusi tanpa mengurai stack dasar.

• VM bytecode dan interpreter sering dikaitkan dengan bahasa pemrograman tujuan umum, tetapi juga bisa sangat berguna secara mengejutkan dalam konteks lain seperti berikut:

  • eBPF: Mekanisme ekstensi Linux kernel.
  • Bahasa ekspresi DWARF: Digunakan di debugger seperti GDB dan LLDB.
  • Format file RAR: Mencakup encoding bytecode untuk transformasi data kustom.

• Microsoft SQL Server secara internal menggunakan pohon objek, tetapi keluaran rencana kueri tetap berbentuk tabel, yang menunjukkan sulitnya merender pohon objek menjadi tabel.

• Programmer sering kali tahu persis lookup indeks mana yang harus terjadi di dalam loop, sehingga dalam beberapa kasus menulis bytecode secara langsung atau menggunakan bahasa imperatif tingkat tinggi bisa lebih menguntungkan daripada SQL. Mengekspresikan hal ini dengan SQL bisa menjadi beban.

• Jika bottleneck tidak berada pada eksekusi bytecode (misalnya kecepatan memori atau disk), mengubahnya menjadi native code melalui kompilasi JIT mungkin tidak selalu diperlukan.

• Banyak bahasa pemrograman seperti Python, Ruby, dan Lua secara internal menggunakan bytecode atau AST. Karena keputusan desain basis data, statement yang mudah di-parse dapat berguna untuk implementasi pustaka pihak ketiga atau ORM yang rentan menimbulkan kesalahan.