Kisah SQLite yang Jarang Diketahui
(corecursive.com)- Ringkasan podcast wawancara dengan pengembang SQLite, Richard Hipp (38 menit, tersedia transkrip)
- Pekerjaan utamanya adalah pengembang perangkat lunak untuk kapal perusak Angkatan Laut Amerika Serikat
→ Informix yang digunakan di dalam kapal sering error, server mati, dan koneksi terputus
→ Karena ini kapal perang, bahkan jika terkena kerusakan saat pertempuran, sistem harus tetap kokoh dan berjalan baik tanpa menampilkan popup “Tidak dapat terhubung ke DB”.
Transaksi juga tidak diperlukan, dan data harus bisa dibaca ke RAM dalam situasi apa pun
→ Ia mencari mesin SQL DB yang bisa berjalan tanpa server, tetapi tidak ada, jadi memutuskan membuatnya sendiri
SQLite V1 (tahun 2000)
- Ia menulis mesin bytecode yang mengompilasi dan mengeksekusi query dengan menganggap pernyataan SQL sebagai program
- Sebenarnya tidak dipakai di proyek tersebut (pelanggan ingin menggunakan Informix)
- Ia memakainya untuk pengembangan, lalu merilisnya di internet, dan orang-orang mulai menggunakannya
- Ia mulai melihat komentar seperti “Saya menjalankan SQL DB di Palm Pilot”, dan itu menarik perhatian orang. Hal itu mendorongnya untuk terus mengerjakannya.
Motorola
- Antara 2001~2002, Motorola menelepon dan mengatakan mereka akan memasukkan SQLite ke OS ponsel baru mereka
- Mereka mengatakan akan membayar jika fitur yang dibutuhkan didukung
- Saat itulah ia pertama kali mengetahui bahwa open source bisa menghasilkan uang
- Sekitar $80,000, yang menurut standar sekarang bukan jumlah besar, tetapi baginya itu nilai yang sangat mengejutkan.
- Ia mengerjakan proyek itu bersama tiga rekan kerjanya, dan dari sanalah semuanya dimulai
America Online Phones
- Setelah itu, pihak berikutnya yang menghubungi adalah AOL
- Saat itu masih era pengiriman CD lewat pos, dan CD itu memerlukan database
- Artinya mereka ingin menyertakan SQLite di dalam CD dan membutuhkan fitur baru
Symbian OS dan Nokia
- Ia pergi ke London saat Thanksgiving untuk menghadiri rapat (karena di Inggris tidak ada Thanksgiving)
- Mereka menginginkan DB untuk Symbian OS, dan SQLite bersaing dengan DB lain (2 open source, 7 komersial)
- Sembilan DB lainnya diberi kesempatan untuk melakukan tuning, tetapi pada akhirnya SQLite yang menang
Bus Factor [1] dan konsorsium
- Bus factor adalah metrik yang menunjukkan berapa banyak orang yang harus “tertabrak bus” agar pengembangan berhenti
- Walau ia sudah bekerja penuh waktu bersama beberapa orang, dari pihak Symbian muncul pendapat bahwa bus factor harus ditingkatkan
- Gagasannya adalah memulai SQLite Consortium untuk mendanai proyek dan membuat lebih banyak orang terlibat dalam jangka panjang
- Ia sempat mengusulkan ide gila seperti memberi hak suara kepada semua anggota konsorsium
- Mitchell Baker dari Mozilla Foundation mendengar ini dari suatu tempat lalu menelepon
→ “Richard, kamu salah total. Saya akan memberi tahu cara membentuk konsorsium.”
→ Lalu ia mulai menyusun aturannya
→ “Pengembang harus memegang kendali. Keputusan mereka harus final. Hanya karena bergabung bukan berarti mendapat hak suara.”
→ “Perusahaan yang menggunakan ini mendapatkan kehormatan karena menyumbang dana, tetapi keputusan akhir harus ada pada Anda.”
→ Ia sangat tegas dan merapikan semuanya. Ia seorang pengacara. - Saat Richard bertanya, “Bagaimana membuat orang mau ikut? Apa insentifnya?”,
→ “Jangan khawatir. Mereka akan ikut. Dan kalau benar dilakukan seperti ini, Mozilla akan menjadi anggota pendiri.” - Dengan dukungan Mozilla, Symbian, dan Adobe, konsorsium dimulai bersama tiga perusahaan tersebut
→ Awalnya ketika Symbian mengatakan konsorsium diperlukan, ia tidak tahu harus berbuat apa. Ia juga tidak tahu bagaimana Mitchell Baker mendengar soal itu dan menelepon, tetapi semuanya menjadi perjalanan yang luar biasa.
Enter Android : awal mula Android
- Karena semua smartphone menggunakan SQLite, Richard bisa melihat perkembangan smartphone awal dari berbagai sisi
- Pada 2005 ia mengadakan rapat dengan Android. Saat itu Android maupun iPhone belum dirilis
- Ia melakukan debug SQLite dengan menghubungkan ke ponsel mirip BlackBerry yang memiliki layar kecil di atas dan keyboard QWERTY penuh
- Men-debug dengan GDB pada ponsel yang terhubung ke jaringan telepon sungguhan adalah pengalaman yang luar biasa
- Pada saat itu tidak ada seorang pun di Motorola, Symbian, atau Nokia yang melakukan hal seperti itu, dan dari situlah ia tahu Android akan menjadi sangat besar
Guy, This Is Important : teman-teman, ini sangat penting
- Pada masa itu, vendor lain memiliki siklus pembaruan hardware dan software yang sangat panjang, sekitar 30 hari, tetapi Android memasukkan OS baru ke ponsel yang terhubung ke jaringan nyata beberapa kali sehari.
- Ponsel prototipe Android yang ia terima di bawah NDA memiliki casing seperti hasil 3D printing, tetapi masih cukup layak untuk dibawa-bawa.
→ Produk perusahaan lain berupa breadboard besar dan prototipe, bahkan tidak terhubung ke jaringan, jadi tidak bisa dipakai sebagai telepon - Ia ingin memberi tahu orang-orang di Motorola dan Symbian, “Ini penting, kalian harus menyelesaikan ini,” tetapi tidak bisa mengatakannya (karena NDA), dan itulah yang membuat perbedaannya
Testing and Aviation Standards : pengujian dan standar avionik
- Adam (pewawancara): “Saat ini DB Richard berada dalam kondisi yang benar-benar hidup. Timnya berbakat dan sangat mampu, tetapi pada dasarnya ini adalah perusahaan konsultasi perangkat lunak beranggotakan 1~4 orang yang mendukung DB yang dipakai di semua ponsel Android. Para pengembang DB sangat serius, dan mereka benci jika ada masalah pada data.”
- Kami dengan naif selalu membanggakan bahwa SQLite tidak punya bug, tetapi Android dengan jelas membuktikan bahwa kami salah.
- Kami pikir mungkin saja membuat perangkat lunak tanpa bug, tetapi ketika software dipasang di jutaan perangkat, sungguh mengejutkan betapa banyak bug yang bisa muncul.
- Sekitar waktu itu, mereka bekerja dengan Rockwell Collins, perusahaan avionik, dan dari sanalah mereka diperkenalkan pada konsep DO-178B [2].
→ DO-178B adalah standar kualitas untuk produk penerbangan yang kritikal terhadap keselamatan, dan tidak seperti standar kualitas lain, dokumennya “bisa dibaca”
→ Harganya hanya beberapa ratus dolar dan tipis, jadi ia sangat menyarankan untuk membacanya - Mereka benar-benar mulai mengikuti proses DO-178B, salah satunya adalah 100% MCDC Test Coverage
- MCDC(Modified Condition / Decision Coverage) [3] berarti pengujian harus melewati setiap cabang individual setidaknya sekali
- Butuh satu tahun dengan ritme 60 jam per minggu agar SQLite mencapai 100% MCDC. Itu sangat, sangat sulit. Ia harus bekerja 12 jam sehari dan sangat kelelahan.
- Cakupan tes 90~95% itu mudah, tetapi 5% sisanya benar-benar sulit. Namun setelah melakukannya selama setahun dan akhirnya mencapai 100%, laporan bug dari Android berhenti datang
- Sejak saat itu mulai benar-benar bekerja, dan perbedaannya sangat besar. Setelah itu, selama 8~-9 tahun tidak ada bug.
Puluhan miliar pengujian
- Yang pertama ditulis dalam TCL(Tool Command Language) dan merupakan tes pengembang biasa
- Tes TCL pertama itu masih dipelihara dan tetap dipublikasikan. Memang tidak 100%, tetapi menguji semua fitur SQLite secara rinci.
- Cakupan MCDC 100% disebut TH3 dan tidak dipublikasikan (proprietary)
- Mereka sempat mencoba menjualnya ke perusahaan penerbangan untuk menghasilkan uang, tetapi tidak satu pun terjual, jadi tidak efektif untuk itu..
- Tetapi itu sangat membantu menjaga produk mereka tetap kokoh dan memungkinkan penambahan fitur baru serta perbaikan bug dengan cepat
- Sulit menghitung jumlah tesnya, tetapi 100 ribu tes individual diparameterkan sehingga menghasilkan puluhan miliar eksekusi tes
- Mereka punya checklist, dan sebelum rilis melakukan pengujian setidaknya selama 3 hari
- Mereka sengaja menguji di berbagai OS
→ Sekarang hampir semua perangkat little-endian, tetapi dulu banyak juga yang big-endian. Karena itu mereka menjalankan tes big-endian di PowerPC iBook
→ Mereka menguji di semua platform dan OS yang bisa mereka jangkau: platform 32-bit, ARM dan Intel, platform 64 Bit, Windows, Linux, Mac, OpenBSD, dan lainnya
→ Ada beberapa test suite yang berbeda, termasuk TCL asli, TH3, dan juga Fuzzer (fuzz testing) yang berjalan terus-menerus. - Ada juga SQL Logic test
→ Sekumpulan besar pernyataan SQL buatan Shane Harrelson sekitar 10 tahun lalu
→ Mereka mengujinya di semua DB yang bisa dijangkau, dan semua mesin DB gagal menjawab lalu mengalami segmentation fault, termasuk SQLite. Kecuali Postgres.
→ Hanya Postgres yang selalu mengeluarkan hasil dan tidak ditemukan cacat. Para pengembang Postgres bilang kami tidak berusaha cukup keras.. mungkin memang bisa membuat Postgres error, tetapi kami sangat terkesan
→ Bahkan Oracle versi komersial pun crash, dan DB2 juga crash
→ Poin pentingnya adalah mereka membuat SQLite menghasilkan jawaban yang sama untuk semua query tersebut
Building From First Principles
- Saat mulai menulisnya, ia mencoba mencari referensi tentang cara membuat mesin SQL DB, tetapi tidak ada. Jadi ia harus membuatnya sendiri, dan itu benar-benar misi yang mandiri.
- Banyak teori berkembang di MIT, Harvard, dan Berkeley, tetapi jika tidak belajar di kampus-kampus itu, seseorang bahkan tidak tahu teori-teori tersebut ada, apalagi cara menemukannya.
- Jika dilihat, model Volcano yang dipakai Postgres dan model bytecode yang dipakai SQLite pada akhirnya berkonvergensi ke ide yang sama
- Dari atas terlihat berawal dari tempat yang sangat berbeda, tetapi kami berkonvergensi ke wilayah yang sama dalam hal bagaimana membuatnya lebih cepat
- Ia menganggap ini semacam pembuktian secara teoretis: dua jalur pengembangan independen menghasilkan jawaban yang sama
- Misalnya, ia sama sekali tidak tahu tentang Covering Index, tetapi saat menghadiri konferensi PHP di Jerman, David Axmark dari MySQL juga hadir dan memberikan presentasi
→ Dalam presentasi itu dijelaskan bagaimana MySQL membuat Covering Index
→ Jika indeks DB memiliki beberapa kolom, dan query hanya memakai kolom-kolom awal pada indeks sementara jawabannya ada di kolom sisanya, maka DB bisa memakai indeks saja tanpa melihat tabel asli, sehingga pekerjaan menjadi lebih cepat
→ Jadi ketika pulang dengan pesawat dan kursinya tidak terlalu penuh, ia membuka laptop dan mengimplementasikan covering index SQLite di atas Samudra Atlantik
B-Trees and The Art of Computer Programming
- Banyak hal memang harus dibuat sendiri. Tidak ada yang pernah mengajarinya B Tree. Ia hanya pernah mendengarnya.
- Saat hendak mengembangkan B-tree sendiri, ia menemukan TAOCP karya Don Knuth di rak bukunya, mencari bagian B-tree, dan di sana algoritmanya dijelaskan
- Yang lucu, buku itu menjelaskan algoritma pencarian dan penyisipan B-tree secara rinci, tetapi tidak memberikan algoritma penghapusan. Itu dijadikan soal latihan di akhir bab, jadi sebelum membuat B-tree sendiri ia harus menyelesaikan soal itu. “Terima kasih Don, saya sangat berterima kasih.”
- Orang zaman sekarang setidaknya perlu membaca atau minimal menelusuri TAOCP
Freedom to Build It Yourself : kebebasan untuk membangunnya sendiri
- SQLite tidak memiliki dependensi pada apa pun selain yang dibuat sendiri oleh Richard (kecuali C compiler dan libc). Ia bahkan membuat sistem version control dan bug tracker sendiri. Itu memberinya kebebasan
- Freedom berarti mampu mengurus diri sendiri
- Orang yang bepergian backpacking sambil membawa semua kebutuhan di punggung mereka merasa bebas karena mereka bisa merawat diri sendiri
- Jika Anda membuat semuanya sendiri, ada kebebasan di dalamnya karena Anda tidak terikat pada orang lain
- Misalnya jika SQLite 2 saat itu memilih Berkeley DB sebagai storage engine
→ Pada masa itu Berkeley DB memang open source, tetapi kemudian diakuisisi Oracle dan menjadi model proprietary dual-source, sehingga tanpa membayar biaya lisensi Anda tidak bisa mendapatkan source code versi terbarunya - Sekarang parser generator SQLite bukan Yak atau Bison, melainkan buatan sendiri yang disebut Lemon, sehingga ketika butuh fitur bahasa baru mereka bisa memodifikasinya tanpa terikat pada alat lain
- Pada awal 2000-an semua proyek menggunakan CVS, jadi ia juga memakainya, tetapi memasuki pertengahan 2000-an mulai muncul gagasan distributed version control
Membangun Fossil
- Setelah melihat Git dan Mercurial serta merangkum kebutuhannya, ia memutuskan mengembangkan sistem version control sendiri
- Kini Fossil bekerja dengan baik dan telah menjadi proyek tersendiri
- Linus Torvalds membuat Git untuk mendukung pengembangan Linux Kernel, jadi jika Anda bekerja terkait Linux Kernel, Git adalah sistem version control yang sempurna
- Fossil adalah sistem version control yang pas untuk mengerjakan SQLite. Karena ia membuatnya sendiri, sistem itu memenuhi kebutuhannya secara tepat
- Dengan mengembangkannya sendiri, Anda dapat mengendalikan takdir sendiri, memiliki lebih banyak kebebasan, dan tidak bergantung pada pihak ketiga
Menjadi mandiri
- Apa sebutan untuk orang yang keluar dari kota lalu hidup dengan menanam makanannya sendiri? Survivalist (penganut survivalisme)? Atau Prepper (orang yang bersiap)?
“Seperti yang mungkin Anda lihat bahkan saat berkomunikasi dengan saya, Gmail saya agak aneh. Email sering terus-menerus memantul balik. Jadi saya ingin membuat mail server sendiri. Bahkan ketika kami sedang menyiapkan pertemuan ini, saya juga sedang menulis catatan terkait itu. Mungkin tidak lebih sulit daripada menulis mesin DB, tetapi saya tidak ingin terikat pada Gmail. Saya tidak ingin mereka mengendalikan nasib saya. Saya tidak ingin mereka mengendalikan catatan semua percakapan saya. Saya ingin mengendalikannya sendiri, jadi meskipun itu menyakitkan dan banyak pekerjaan, saya akan berusaha mencari solusi yang bisa saya kendalikan sendiri. Saya bisa menyewa virtual machine di cloud dan menjalankannya tanpa bergantung pada pihak ketiga.” - Jika seseorang datang dan berkata mereka akan menyelesaikan masalah Anda, Anda harus tahu bahwa mereka juga akan mengambil kebebasan Anda. “Kalau ingin bebas, lakukan sendiri.”
Saran untuk orang lain
- Saya memulai dari ide gila untuk membuat mesin DB yang membaca dan menulis langsung ke disk tanpa memerlukan server.
- Jika Anda bertanya kepada para ahli, mereka akan berkata, “Itu tidak mungkin. Tidak akan pernah bekerja. Itu ide bodoh.”
- Untungnya saya tidak mengenal para ahli seperti itu, jadi saya langsung melakukannya, dan semua hal ini pun terjadi.
- Jangan terlalu banyak mendengarkan para ahli. Kerjakan hal yang masuk akal. Selesaikan masalah Anda sendiri
--
[1] Bus Factor : tingkat risiko tim menjadi krisis jika anggota tim tertabrak bus.
- Ini adalah indikator risiko yang muncul ketika informasi dan fungsi tidak dibagikan antar anggota tim.
- Menaikkan angka ini membantu informasi tersebar dan mencegah pekerjaan terkonsentrasi pada orang tertentu.
[2] DO-178B : pertimbangan perangkat lunak dalam sertifikasi sistem dan peralatan pesawat (Software Considerations in Airborne Systems and Equipment Certification )
- Diadopsi oleh FAA sebagai metode pembuktian kesesuaian untuk sertifikasi software penerbangan
[3] MCDC : Modified Condition / Decision Coverage
- Metode merancang test case agar ketika ada beberapa ekspresi kondisi, masing-masing kondisi individual memengaruhi hasil ekspresi keseluruhan secara independen tanpa dipengaruhi kondisi lain
16 komentar
Ternyata ada tulisan sebagus ini. Syukurlah bisa membacanya dalam versi terjemahan.
Tulisan yang membuat saya membacanya berulang kali. Terima kasih.
Jika ingin bebas, Anda harus melakukannya sendiri.
Lakukan hal yang masuk akal.
Selesaikan masalah Anda sendiri.
Ini benar-benar tulisan yang menarik!
"Cakupan pengujian 90~95% itu mudah, tetapi 5% sisanya benar-benar sulit. Namun setelah melakukannya selama 1 tahun dan akhirnya mencapai 100%, laporan bug dari Android pun berhenti datang"
Ternyata bisa seperti itu.
Saya membacanya dengan baik. Terima kasih!
Sangat enak dibaca. Terima kasih
Saya membacanya dengan baik.
Saya membacanya dengan senang!
Saya membacanya dengan senang hati. Terima kasih.
Sangat enak dibaca.
Sepertinya merangkum dan menatanya justru akan lebih sulit.
Saya membacanya dengan baik. Membuat saya banyak berpikir. Terima kasih :)
Saya membacanya dengan baik. Terima kasih!
Saya membacanya dengan baik.
Saya membacanya sampai tidak terasa waktu berlalu, haha.
Saya jadi malu karena dulu meremehkannya sebagai DB embedded yang sederhana ^^;
Saya memakainya sambil mengira ini cuma DBMS sederhana untuk pengembangan lokal, tetapi ternyata sama sekali tidak sederhana!!
Saya membacanya dengan sangat menyenangkan.
Saat ini, ada lebih dari 1 triliun instance SQLite yang beroperasi di seluruh dunia.
Semua smartphone yang jumlahnya lebih dari 4 miliar unit (Android, iOS)
Mac/Windows
Browser FF/Chrome/Safari
PHP/Python
Skype/iTunes/Dropbox/Turbotax
Sebagian besar set-top box dan TV
Sistem multimedia di sebagian besar mobil
https://www.sqlite.org/mostdeployed.html