- SQLite sangat cepat. Pada server umum single-thread seharga ~40€/bulan, SQLite dapat mempertahankan ~168.000 operasi baca dan ~8.000 operasi tulis secara bersamaan
- Karena SQLite adalah library embedded yang dirancang untuk aplikasi sisi klien seperti sistem embedded, ponsel, dan aplikasi desktop, database SQLite harus berada bersama server aplikasi dan tidak dapat diakses melalui jaringan
- Bagaimana menggunakan SQLite dalam situasi yang membutuhkan lebih dari satu mesin?
- Proyek akhir pekan bisa saja meledak popularitasnya dan harus diskalakan dengan cepat
- Salah satu persyaratan CTO mungkin adalah menerapkan layanan high availability di setidaknya 2 pusat data yang berbeda
- Dalam beberapa tahun terakhir, muncul sejumlah proyek yang mencoba mengubah SQLite menjadi database backend untuk aplikasi backend
- Ini adalah tulisan yang menelaah apakah hal tersebut merupakan perubahan paradigma yang memungkinkan organisasi menghadirkan pengalaman pengguna yang lebih baik lebih cepat, atau sekadar hype pemasaran yang didorong perusahaan-perusahaan yang ingin membesar-besarkan "Unique Selling Proposition" mereka
Menggunakan SQLite sebagai database edge
- SQLite kini dipromosikan bukan hanya sebagai database backend sederhana, tetapi sebagai database edge
- Pemain yang paling menonjol adalah Cloudflare D1, fly.io yang menggunakan LiteFS, dan Turso
- Sebagian besar turunan SQLite bekerja dengan cara yang mirip
- Ada database utama di suatu tempat yang menerima operasi tulis, lalu direplikasi secara asinkron ke wilayah lain
- Replikasi umumnya dilakukan dengan men-stream log semua transaksi yang dijalankan pada database, yaitu SQLite Write-Ahead Log
- Dalam arsitektur seperti ini, secara teori operasi baca bisa ditangani di pusat data edge, tetapi operasi tulis tetap harus diteruskan ke lokasi pusat
- Dalam praktiknya, tentu pelanggan tidak ingin menyelesaikan pesanan di aplikasi e-commerce, pesanan sudah disetujui di database utama SQLite, tetapi replika baca lokal tertinggal dan belum menerima data terbaru sehingga menampilkan pesan kesalahan bahwa data tidak ditemukan
- Selamat datang di "dunia eventual consistency yang menyakitkan"
Solusi LiteFS dan keterbatasannya
- LiteFS mengusulkan solusi yang terasa seperti hack. Aplikasi mengatur cookie
__txiduntuk melacak transaksi terakhir yang dimiliki replika lokal, lalu jika terlalu usang, query baca diteruskan ke database utama. - Kini aplikasi menjadi terikat erat dengan database dan reverse proxy
- LiteFS juga tidak menyinggung fakta bahwa ia hanya mendukung sekitar 100 operasi tulis per detik
Kekurangan utama sebagian besar sistem SQLite terdistribusi
- Sebagian besar sistem SQLite terdistribusi tidak mendukung transaksi interaktif yang melakukan sejumlah komputasi di antara query-query berbeda dalam satu transaksi
- Hanya satu transaksi tulis yang bisa aktif pada satu waktu. Pada database SQLite biasa, ini umumnya tidak masalah karena sebagian besar operasi tulis tidak berlangsung lebih dari puluhan mikrodetik
- Namun ketika latensi jaringan diperkenalkan di antara aplikasi dan database SQLite, sistem pun runtuh. Database akan terkunci selama waktu round-trip transaksi dan akan terbatas pada hanya beberapa operasi tulis per detik
- Turso "menyelesaikan" ini dengan batch. Beberapa query dapat digabung dalam satu batch dan dijalankan sebagai satu transaksi. Cloudflare D1 "menyelesaikan" masalah ini dengan batch dan stored procedure
Bagaimana jika ada solusi yang lebih sederhana?
- Untuk aplikasi web, sebenarnya sudah ada cara yang sangat sederhana dan kuat untuk membuatnya sangat cepat secara global: HTTP caching dengan header
Cache-ControldanETag - Dengan HTTP caching, aplikasi web tidak perlu memakai teknik mirip database dengan konsistensi lemah, sehingga tidak menjadi terlalu rumit atau rentan terhadap race condition
- Penulis tulisan ini menghabiskan banyak waktu dalam buku barunya, "Cloudflare for Speed and Security", untuk menjelaskan berbagai strategi caching yang bukan hanya membuat aplikasi web cepat, tetapi juga mampu menangani banyak pengguna bersamaan dengan sumber daya minimal
Database sebagai abstraksi
- Latensi bukan satu-satunya masalah yang ingin dipecahkan SQLite terdistribusi. Masalah lainnya adalah kompleksitas operasional
- Mengelola klaster server yang saling terhubung melalui jaringan itu sulit dan sering berujung pada downtime serta hilangnya pendapatan. Belum lagi pengelolaan database yang memerlukan perawatan berkelanjutan dan budaya keamanan yang baik untuk menghindari bencana seperti yang dialami GitLab pada 2017
- Karena itu, idenya adalah membundel database bersama aplikasi dan menempatkan semuanya di satu server
- Ini bagus bila hanya ada satu developer, tetapi di organisasi besar biasanya ada orang atau tim khusus yang menangani pemeliharaan server database
- Inilah alasan database yang diakses melalui socket, bukan library embedded, sebenarnya merupakan abstraksi yang hebat bukan sebagai abstraksi teknis, melainkan abstraksi organisasional. Saat pengembangan, itu bisa berupa container sederhana yang berjalan di mesin developer, tetapi di produksi bisa berupa apa saja, mulai dari container yang berjalan di server yang sama dengan aplikasi hingga klaster terdistribusi yang diakses melalui jaringan. Developer hanya perlu mengganti satu variabel konfigurasi,
DATABASE_URL, dan tim operasional menangani sisanya - Sebaliknya, sistem berkas Unix tradisional adalah abstraksi yang tidak cocok untuk komputasi terdistribusi. Memang ada NFS (Network File System), tetapi karena sistem berkas Unix dirancang untuk akses dari satu mesin, performanya jauh dari ideal. Sebaliknya, protokol S3 adalah abstraksi yang sangat baik untuk menyimpan data tak terstruktur dalam jumlah besar secara efisien, skalabel, dan andal. Developer cukup memakai SDK yang kompatibel dengan S3 lalu melupakannya; tim operasional atau penyedia cloud akan menangani performa, durabilitas, keandalan, dan semuanya
Kesimpulan
- SQLite memang database yang luar biasa, tetapi bagi sebagian besar tim, lebih baik menghindari SQLite dan memilih PostgreSQL
- Banyak sekali waktu rekayasa telah dihabiskan untuk menjadikan PostgreSQL database backend terbaik. Jika memilih SQLite, pada akhirnya Anda akan dipaksa menciptakan ulang hal-hal yang sudah lama dimiliki PostgreSQL, tetapi dengan cara yang rapuh dan penuh bug
- Gerakan saat ini untuk menjadikan SQLite sebagai database backend dipandang tidak lebih dari kudeta pemasaran oleh perusahaan-perusahaan penjual infrastruktur edge computing yang menyadari bahwa komputasi bukan apa-apa tanpa penyimpanan data. Saran (yang tidak diminta) bagi mereka adalah berinvestasi pada HTTP caching alih-alih membangun CDN dan memaksakan kompleksitas ke aplikasi, karena hasilnya akan jauh lebih baik
- Karena kompleksitas yang ditimbulkan, 99,9% aplikasi backend tidak akan melihat manfaat apa pun dari berpindah ke edge, dan sebaliknya harus fokus menerapkan strategi caching yang baik untuk memberikan pengalaman global yang luar biasa di bawah 100ms
- Dan di sinilah eksperimen SQLite untuk aplikasi server-side berakhir. Kemenangan untuk PostgreSQL
-
"Amatir membahas taktik, profesional membahas logistik. (Amateurs discuss tactics. Professionals discuss logistics.)"
Artinya, untuk meraih keberhasilan, sistem dan proses pendukung yang memungkinkan keputusan-keputusan taktis di lapangan—yakni logistik dan pengelolaan—lebih penting daripada keputusan taktis itu sendiri
Opini GN⁺
- Seperti klaim penulis, penggunaan SQLite pada sebagian besar aplikasi backend tampaknya hanya menambah kompleksitas tanpa memberikan manfaat nyata. Menggunakan database yang sudah teruji dan matang seperti PostgreSQL kemungkinan merupakan pilihan yang lebih baik
- Dorongan vendor infrastruktur edge computing terhadap SQLite tampaknya lebih merupakan bagian dari strategi pemasaran daripada keunggulan teknis. Akan lebih membantu bagi developer aplikasi bila mereka berinvestasi lebih banyak pada HTTP caching dan CDN
- Sebagian besar aplikasi backend dapat menyediakan layanan yang cukup cepat dan skalabel hanya dengan strategi caching yang tepat. Kecuali edge computing benar-benar diperlukan, lebih baik menghindari kompleksitas berlebihan
- SQLite terdistribusi mungkin berguna untuk use case tertentu, tetapi tampaknya masih memiliki keterbatasan untuk digunakan sebagai solusi umum. Tidak mudah memenuhi sekaligus kemudahan pengembangan, performa, dan konsistensi
- Pada akhirnya, yang paling penting adalah memilih teknologi yang sesuai dengan kebutuhan aplikasi dan kemampuan tim. Alih-alih terbawa tren, keputusan harus diambil dengan menganalisis kelebihan dan kekurangannya secara cermat
- Penulis menekankan bahwa SQLite masih memiliki banyak kekurangan untuk digunakan sebagai database backend, tetapi itu tidak berarti SQLite harus sepenuhnya disingkirkan, karena mungkin ada use case lain yang bisa memanfaatkan keunggulannya
3 komentar
Daripada membahas mana yang terbaik antara Postgres dan sqlite,
lebih baik memikirkan mana yang lebih cocok untuk situasi kita di antara keduanya, bukan?
Karena yang terbaik akan berbeda tergantung situasinya.
Komentar Hacker News