DuckDB atau SQLite: analitik cepat berhadapan dengan penulis serentak

Untuk agregasi atas banyak baris dan analisis lokal, pilih DuckDB. Untuk catatan aplikasi yang dicari dan diubah lewat transaksi kecil, pilih SQLite. Keduanya berjalan tertanam tanpa server basis data terpisah, tetapi keunggulan analitik DuckDB perlu ditimbang bersama cara tiap mesin menangani penulis serentak.

Perbedaan praktisnya muncul saat berkas yang sama diakses dari beberapa utas atau proses. SQLite menerima banyak pembaca dan giliran penulis dari proses berbeda, sedangkan penulis DuckDB pada berkas native bekerja dalam satu proses kecuali ada lapisan tambahan. Karena itu, bentuk kueri, frekuensi perubahan, dan susunan aplikasi lebih menentukan daripada satu angka kecepatan agregasi.

Peta pilihan menurut beban kerja

OLAP merangkum atau menggabungkan banyak catatan sekaligus; OLTP mengerjakan transaksi pendek yang biasanya menyentuh sedikit catatan. Pembedaan ini menunjukkan pekerjaan dominan, bukan larangan bagi mesin lain untuk menjalankan SQL yang sama. Matriks ringkasnya sebagai berikut:

• Pemindaian dan agregasi: DuckDB cocok ketika kueri menghitung total, mengelompokkan hasil, atau menggabungkan tabel besar sambil membaca sebagian kolom. Beban seperti ini umum dalam analisis kumpulan data lokal dan pengolahan berkala.
• Pencarian dan pembaruan kecil: SQLite cocok ketika aplikasi mengambil satu catatan, mengubah statusnya, lalu segera menyelesaikan transaksi. Indeks dan penyimpanan berorientasi baris melayani pola akses tersebut.
• Penulis: SQLite mengatur giliran transaksi tulis pada berkas yang sama, termasuk ketika permintaan datang dari proses berbeda. DuckDB menerima beberapa utas penulis dalam proses pemilik berkas native, tetapi akses tulis dari banyak proses memerlukan rancangan tambahan.
• Peran berkas: SQLite sering menjadi penyimpanan utama sekaligus format data portabel aplikasi. DuckDB lebih menarik ketika pekerjaan utamanya adalah menganalisis data dalam berkas native atau sumber lain seperti Parquet.

Ukuran tabel sendiri tidak menyelesaikan pilihan. Tabel besar yang sering menerima perubahan kecil berbeda dari tabel sebesar itu yang dibaca berulang kali untuk laporan. Pertanyaan kuncinya ialah seberapa banyak data disentuh per kueri dan apakah jalur tulis harian tetap lancar ketika analisis berjalan.

Mengapa benchmark memberi jawaban berbeda?

Studi PVLDB tahun 2022 memakai SQLite 3.38.0 dan DuckDB 0.3.2 dengan DuckDB dibatasi pada satu utas; SQLite dalam mode WAL mencatat throughput tertinggi pada beban transaksi TATP, sedangkan DuckDB lebih cepat pada semua kueri analitik Star Schema Benchmark yang diuji. TATP mengukur transaksi ringan dengan satu klien dalam eksperimen itu, sementara kueri analitiknya membaca dan menggabungkan tabel untuk menghasilkan ringkasan. Hasil tersebut berlaku pada konfigurasi, perangkat, dan versi yang diuji, bukan sebagai rasio kecepatan tetap untuk aplikasi sekarang.

Susunan datanya menerangkan arah perbedaan. SQLite menyimpan catatan berorientasi baris dalam struktur B-tree dan mengeksekusi operasi baris demi baris. Ketika aplikasi mengambil catatan tertentu melalui kunci atau indeks, susunan tersebut sesuai dengan pencarian dan pembaruan terarah.

DuckDB menyimpan data secara kolumnar dan mengeksekusi kueri dalam kelompok nilai. Agregasi yang hanya membutuhkan beberapa kolom dapat bekerja pada kolom yang relevan, lalu memanfaatkan pemrosesan tervectorisasi untuk mengurangi pekerjaan per nilai. Itu membantu menjelaskan hasil analitiknya pada uji tersebut, sementara transaksi kecil yang terus-menerus menuntut pola kerja berbeda. Jika data harus dimuat ulang setiap kali laporan dibuat, waktu impor juga masuk ke biaya keseluruhan, bukan hanya waktu kuerinya.

Apa arti satu penulis SQLite?

Panduan penggunaan SQLite menyatakan bahwa banyak pembaca dapat mengakses basis data bersamaan, tetapi hanya satu penulis aktif untuk tiap berkas pada suatu saat. Penulis lain bergiliran. Untuk transaksi singkat, antrean ini sering cukup; ketika banyak proses harus menyelesaikan penulisan panjang secara serentak, waktu tunggu menjadi bagian dari rancangan aplikasi.

Bayangkan contoh bersyarat: proses pemesanan dan proses pembaruan stok sama-sama mengubah catatan dalam satu berkas SQLite. Keduanya boleh mengajukan transaksi, tetapi perubahan tidak dieksekusi sebagai dua penulisan aktif sekaligus. Aplikasi dapat menunggu kunci, mengatur antrean, atau memisahkan berkas sesuai batas data yang masuk akal; pemisahan terakhir juga mengubah cara menjaga konsistensi lintas data.

Dokumentasi WAL SQLite menjelaskan bahwa pembaca dapat terus bekerja ketika penulis menambahkan perubahan ke log, tetapi WAL tetap hanya mengizinkan satu penulis aktif. Transaksi baca memakai titik pandang yang tetap selama berjalan. Bacaan yang berlangsung lama bisa menahan checkpoint, sehingga isi log belum dapat seluruhnya dipindahkan kembali ke berkas utama dan ukuran WAL dapat bertambah. Mode ini membantu pembaca dan penulis berjalan bersamaan tanpa mengubah batas penulis per berkas.

Utas DuckDB bukan proses DuckDB

Aturan konkurensi DuckDB mengizinkan beberapa utas menulis dalam satu proses yang membuka berkas native, sedangkan penulisan dari proses berbeda membutuhkan protokol Quack yang masih beta dalam dokumentasi; opsi DuckLake memakai format lain dengan katalog PostgreSQL. Dalam mode baca saja, beberapa proses dapat membuka berkas yang sama. Perbedaan utas dan proses ini penting bagi aplikasi yang menjalankan pekerja terpisah, bukan hanya banyak tugas di dalam satu program.

Dalam satu proses, penambahan baris dari beberapa utas tidak berbenturan, dan pembaruan pada baris berbeda dapat berjalan bersama. Jika dua utas mencoba mengubah baris yang sama, pengendalian konkurensi optimistis dapat menggagalkan salah satu transaksi. Artinya, dukungan banyak penulis bukan janji bahwa semua perubahan serentak selalu berhasil; aplikasi tetap perlu menangani konflik transaksi.

Misalnya secara bersyarat, satu proses impor yang menerima data lalu menjalankan beberapa kueri analitik sesuai dengan pola akses native DuckDB. Beberapa proses independen yang masing-masing membuka berkas itu untuk menulis merupakan susunan berbeda. Lapisan koordinasi dapat mengubahnya, tetapi juga menambah komponen dan pekerjaan operasional.

Berkas portabel, ukuran paket, dan pilihan akhir

Penjelasan rancangan DuckDB menyebut berkas native tunggal, integrasi Python dan R, serta dukungan Parquet melalui ekstensi. Kombinasi itu berguna ketika analisis berlangsung dekat dengan data dan hasilnya tidak perlu lebih dulu dipindahkan ke server basis data tersendiri. SQLite juga menyimpan basis data dalam berkas portabel yang lazim dijadikan format data aplikasi, termasuk ketika isinya perlu dibuka kembali pada perangkat lain.

Ukuran berkas data dan ukuran pustaka yang disertakan ke aplikasi merupakan biaya berbeda. Data kolumnar dapat terkompresi dengan baik, tetapi mesin analitik yang ditanamkan juga memengaruhi ukuran paket dan proses kompilasi. Sebaliknya, indeks, pola nilai, dan pilihan jurnal dapat mengubah ukuran penyimpanan SQLite. Tidak ada angka ukuran yang adil tanpa skema, data, serta konfigurasi paket yang sama.

Jika berkas menjadi sumber utama data aplikasi dengan banyak transaksi pendek, SQLite adalah titik awal yang masuk akal. Jika pekerjaan utama memindai, menggabungkan, dan merangkum data lokal, DuckDB lebih sesuai. Ketika transaksi dan analitik sama pentingnya, SQLite dapat menyimpan data operasional sementara DuckDB membaca salinan atau ekspor untuk analisis; konsekuensinya ialah pekerjaan pemindahan data dan jeda sebelum laporan mencerminkan perubahan terbaru.

Baca juga:

• Loom atau Clipchamp: pesan cepat berhadapan dengan editor lengkap
• Zoho Books atau Xero: kurs dolar dan jumlah pengguna membalik pilihan
• Trello atau ClickUp: kesederhanaan murah berhadapan dengan kontrol proyek