Kapan SQLite Unggul

Kebutuhan akan basis data lebih mudah dievaluasi pada awal proyek ketimbang setelah aplikasinya berjalan. SQLite tidak bersaing dengan MySQL atau PostgreSQL, melainkan dengan pembacaan dan penulisan berkas biasa, sebagaimana dirumuskan dokumentasi resminya. Topik ini menyajikan tabel keputusan berdasarkan halaman When to Use SQLite, menjelaskan alasan teknis di balik tiap barisnya, dan menampilkan contoh analitik lokal. Batas nyata SQLite, yaitu penulis tunggal serta ketiadaan pengguna dan jaringan bawaan, dibahas pada bagian penutup.

Tabel keputusan#

Tabel berikut meringkas panduan keputusan dari dokumentasi resmi SQLite ke dalam situasi yang sering dihadapi pengembang. Setiap baris memasangkan satu situasi nyata dengan pilihan yang dianjurkan, dan tiga baris terakhir menunjukkan kapan basis data client-server lebih tepat. Situasi di sisi kiri diambil dari kebiasaan kerja nyata, sedangkan anjurannya mengikuti penjelasan resminya.

Baris kedua menyebut pola local-first, yakni pola aplikasi yang menyimpan dan mengolah datanya di perangkat lokal sehingga jaringan menjadi pelengkap dan bukan kebutuhan utama. Posisi SQLite dalam tabel ini bukan klaim promosi. Dokumentasi resminya merumuskan posisi tersebut dengan kalimat “SQLite does not compete with client/server databases. SQLite competes with fopen()”, yang berarti SQLite bersaing dengan fungsi penulis dan pembaca berkas biasa, bukan dengan mesin server. Tiga bagian berikutnya menjelaskan alasan teknis di balik baris-baris tersebut.

Konkurensi tulis tunggal#

SQLite mendukung pembaca serentak tanpa batas jumlahnya, tetapi hanya mengizinkan satu penulis pada satu saat. Kunci penulisan berlaku untuk seluruh berkas basis data, sehingga dua proses yang menulis bersamaan harus antre. Transaksinya biasanya singkat dan hanya berlangsung beberapa milidetik, sehingga antrean ini jarang terasa pada aplikasi dengan penulis yang sedikit.

Batas tunggal ini menjelaskan tiga baris tabel sekaligus. Aplikasi dengan banyak penulis serentak dari banyak mesin membutuhkan pengaturan tulis terpusat yang hanya diberikan mesin client-server. Situs web yang padat penulisan menghadapi kondisi serupa karena setiap pengunjung yang mengirim data adalah penulis potensial. Sebaliknya, aplikasi perangkat dan situs kecil dengan penulisan yang jarang tidak pernah menyentuh batas tersebut.

Satu peringatan resmi juga berkaitan dengan jaringan. SQLite tidak dirancang untuk berkas basis data yang diletakkan pada sistem berkas jaringan, karena penguncian berkasnya tidak dapat diandalkan pada banyak implementasi jaringan dan risiko kerusakan datanya tidak dapat dicegah sepenuhnya oleh SQLite. Kondisi ini berbeda dari berkas yang hanya dibuka oleh satu mesin karena penguncian di jaringan bergantung pada implementasi sistem berkasnya.

Latensi dan kebebasan jaringan#

Karena tidak ada server, tidak ada pula lompatan jaringan pada setiap query. Query pada SQLite berubah menjadi panggilan fungsi di dalam proses yang sama, sedangkan query ke basis data server harus menempuh sambungan jaringan bolak-balik untuk setiap permintaan. Perbedaan ini tampak pada pola akses yang mengirim banyak query kecil secara beruntun, misalnya saat aplikasi membaca puluhan pengaturan saat memulai.

Kebebasan dari jaringan membawa dua akibat lain. Pertama, tidak ada server yang harus dijaga, sehingga purwarupa dibagikan cukup dengan menyalin satu berkas basis data dan mesin pengembangan tidak memerlukan pemasangan apa pun. Kedua, data berada di dekat kode yang mengolahnya, sehingga aplikasi local-first berfungsi penuh tanpa jaringan dan tetap menyimpan setiap perubahan di perangkatnya.

Ukuran bukan penghalang untuk sebagian besar kasus. Batas teoretis satu basis data SQLite adalah 281 terabyte, tetapi titik nyamannya jauh di bawah angka itu karena berkasnya harus muat di satu sistem berkas lokal. Data berukuran gigabyte hingga puluhan gigabyte masih termasuk wilayah yang nyaman, sedangkan kebutuhan di atasnya lebih cocok didelegasikan ke mesin client-server.

Contoh analitik lokal#

Kasus analitik embedded, yakni analitik yang berjalan di dalam aplikasi tanpa mesin analitik terpisah, memanfaatkan seluruh sifat di atas. Data diimpor sekali ke satu berkas, lalu diolah berulang kali dengan SQL tanpa server yang harus hidup. Pola baca banyak dan tulis jarang seperti ini berada persis di sisi kuat SQLite, karena pembaca serentak tidak pernah mengganggu satu sama lain. Contoh berikut membuat basis data kecil berisi rekapitulasi kunjungan perpustakaan, kemudian mengurutkan dua bulan dengan kunjungan terbanyak.

# membuat basis data kecil untuk simulasi analitik lokal
rm -f analitik.db
sqlite3 analitik.db <<'SQL'
CREATE TABLE kunjungan (bulan TEXT, jumlah INTEGER);
INSERT INTO kunjungan VALUES ('Januari', 120), ('Februari', 98), ('Maret', 141);
SQL
sqlite3 -header -column analitik.db "SELECT bulan, jumlah FROM kunjungan ORDER BY jumlah DESC LIMIT 2;"

 bulan   jumlah
-------  ------
Maret       141
Januari     120

Tanda <<'SQL' yang disebut heredoc mengalirkan baris-baris di antara penandanya ke sqlite3 sebagai masukan, sehingga pembuatan tabel dan pengisian data berjalan dalam satu kali pemanggilan. Opsi -header dan -column membuat sqlite3 menampilkan nama kolom beserta susunan tabelnya, berbeda dari format garis tegak yang bawaan. Seluruh proses, dari membuat berkas sampai membaca hasilnya, berjalan tanpa menyentuh jaringan dan tanpa proses lain yang perlu dihidupkan. Analisis serupa selanjutnya cukup diulang dengan mengganti pernyataan SELECT-nya, sementara berkas datanya tetap satu.

Batas nyata yang perlu diantisipasi#

Selain penulis tunggal, SQLite tidak menyertakan pengelolaan pengguna bawaan. Tidak ada akun, kata sandi, dan hak akses per tabel yang diatur oleh mesinnya, karena siapa pun yang dapat membaca berkasnya dapat membaca seluruh datanya. Pengamanan didelegasikan ke sistem berkas dan ke aplikasi yang membungkusnya, dan SQLite tidak menyertakan enkripsi bawaan. Model sederhana ini wajar untuk data milik satu aplikasi, tetapi tidak cukup bila banyak pengguna dengan hak berbeda perlu dibedakan.

Ketiadaan jaringan bawaan sama fundamentalnya. SQLite tidak membuka port dan tidak mendengarkan sambungan, sehingga program di mesin lain tidak dapat mengakses basis datanya secara langsung. Apabila akses jarak jauh diperlukan, pilihannya adalah membungkus SQLite dengan aplikasi server sendiri atau beralih ke basis data client-server yang memang dirancang untuk itu.

Ketiga batas ini, yaitu penulis tunggal, tanpa pengguna bawaan, dan tanpa jaringan bawaan, adalah garis pemisah yang menentukan keputusan akhir pada banyak proyek. Pemeriksaannya cepat dilakukan karena hanya menyangkut letak berkas dan pola aksesnya. Aplikasi perpustakaan satu komputer yang menjadi contoh sepanjang jalur ini berada jauh di sisi aman dari ketiganya.

Ringkasan#

• SQLite tepat untuk data yang hidup bersama aplikasinya, yaitu perangkat, format berkas aplikasi, purwarupa, analitik lokal, dan situs dengan lalu lintas rendah hingga menengah.
• Batas utamanya adalah satu penulis pada satu saat, tanpa pengelolaan pengguna, dan tanpa akses jaringan bawaan.
• Berkas basis data tidak boleh diletakkan di sistem berkas jaringan karena penguncian berkasnya tidak andal.
• Apabila banyak penulis serentak lintas mesin atau data skala terabyte dibutuhkan, basis data client-server lebih tepat.

Referensi#

• When to Use SQLite — SQLite — Panduan resmi yang menjadi dasar tabel keputusan, batas ukuran 281 terabyte, dan daftar situasi yang lebih cocok untuk mesin client-server.
• How SQLite Works — SQLite — Penjelasan arsitektur serverless yang melatarbelakangi sifat latensi dan pemasangan pada tabel keputusan.