Mengapa penulisan bersamaan tidak diizinkan pada basis data SQLite?

Saya melakukan pemrograman basis data menggunakan Java dengan SQLite.

Saya telah menemukan bahwa hanya satu koneksi pada basis data yang memiliki kemampuan menulis, sementara banyak koneksi sekaligus memiliki kemampuan membaca.

Mengapa arsitektur SQLite dirancang seperti ini? Selama dua hal yang sedang ditulis tidak ditulis ke tempat yang sama dalam database, mengapa tidak bisa dua tulisan terjadi sekaligus?

database concurrency sqlite

— SteelToe
sumber

terkait (mungkin duplikat): SQLite dengan dua proses python mengaksesnya: satu bacaan, satu tulisan

— agas

Karena SQLite dirancang untuk menjadi "lite". Memori rendah dan pemrosesan rendah dengan kinerja. Pikirkan bagaimana Anda akan membuat SQLite menangani banyak penulisan ke file yang sama. Desain saat ini mudah diimplementasikan - seluruh file terkunci dan yang lain harus menunggu. Untuk menangani penulisan konkurensi pada tingkat granularitas yang lebih rendah, diperlukan penguncian baris / halaman yang Anda dapatkan dari RDMS. Jika persyaratan menuntut penulisan konkurensi, maka SQLite bukan kandidat dan sebagai gantinya, Anda harus melihat ke RDBMS yang ringan: en.wikipedia.org/wiki/…

— Thomas Carlisle

Jawaban:

157

Karena "multiple menulis bersamaan" jauh lebih sulit untuk dicapai dalam mesin basis data inti daripada penulis tunggal, pembaca banyak. Ini di luar parameter desain SQLite, dan termasuk kemungkinan akan menumbangkan ukuran kecil dan kesederhanaan SQLite.

Mendukung konkurensi penulisan tingkat tinggi adalah ciri khas mesin basis data besar seperti DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL, dan Sybase. Tetapi secara teknis sulit untuk dicapai, membutuhkan kontrol konkurensi yang luas dan strategi optimasi seperti basis data, tabel, dan penguncian baris atau, dalam implementasi yang lebih modern, kontrol konkurensi multi-versi . Penelitian tentang masalah / persyaratan ini sangat banyak dan telah berlangsung puluhan tahun .

SQLite memiliki filosofi desain yang sangat berbeda dari kebanyakan DBMS server-sentris yang mendukung banyak penulis. Ini dirancang untuk membawa kekuatan SQL dan model relasional ke aplikasi individual, dan memang bisa disematkan dalam setiap aplikasi. Tujuan itu membutuhkan pengorbanan yang signifikan. Tidak menambahkan infrastruktur dan overhead signifikan yang diperlukan untuk menangani beberapa penulis bersamaan adalah salah satunya.

Filosofi dapat diringkas dengan pernyataan pada halaman penggunaan yang sesuai SQLite :

SQLite tidak bersaing dengan database klien / server. SQLite bersaing dengan fopen ().

— Jonathan Eunice
sumber

+1. SQLite adalah database dalam proses. Tidak ada arbiter pusat seperti di DB berbasis server. Para penulis harus langsung bekerja sama dan saling percaya. Seorang penulis jahat bisa membuat kekacauan hanya dengan tidak bekerja sama.

— Jörg W Mittag

Juga, beberapa lingkungan yang dijalankan oleh SQLite mungkin bahkan tidak mendukung banyak proses.

— david25272

Agaknya sebuah tulisan jahat sudah dapat menimbulkan kekacauan dengan tidak bekerja sama. Mereka tidak dapat menggunakan kode SQLite untuk melakukannya, tetapi mereka dapat memiliki kode mereka sendiri, yang bisa saja menjadi panggilan untuk membatalkan tautan ()

— bdsl

Dalam aplikasi bersamaan, tidak ada banyak jalan tengah. Entah Anda mendapatkan konkurensi, konsistensi, dan integritas data dengan benar 100% dari waktu, termasuk dalam kondisi yang menantang dan kasus tepi, atau tidak. Jika tidak, itu rapuh, lambat, dan rawan kecelakaan, dan orang-orang berhenti memercayainya dengan sangat cepat. Tetapi melakukannya dengan benar secara rutin sangat sulit. Tidak ada banyak keadaan di mana penulis dapat, jika tidak ada jumlah besar dukungan inti, mengoordinasikan tulisan yang disisipkan sendiri.

— Jonathan Eunice

@ bdsl Database dalam bentuk apa pun harus menganggap penulis tidak akan berperilaku baik sehingga mereka tidak kehilangan data. Para penulis SQLite memposisikannya sebagai pesaing fopen(), jadi pertimbangkan semua hairiness yang datang dengan penulisan bersamaan ke file teks biasa.

— Blrfl

Karena tidak ada server yang dapat menentukan apakah sesuatu akan ditulis ke tempat yang sama atau tidak. Hanya ada dua proses yang mencoba menulis ke file.

Seperti yang ditunjukkan dalam komentar, penulisan bersamaan juga dapat didukung oleh utas internal. Tidak yakin seberapa baik ini akan bekerja (tidak terlalu memikirkannya). Lagi pula, inilah mengapa SQLite tidak menggunakan utas: Dr Hipp berpikir bahwa utas itu jahat.

Fakta bahwa DR Hipp berpikir bahwa utas adalah kejahatan didokumentasikan dalam FAQ SQLite .

— Goyo
sumber

Ini menjelaskan alasan teknis mengapa penulisan bersama tidak diperbolehkan, tetapi tidak mengapa keputusan desain dibuat.

— Robert Harvey

Keputusan untuk mendesain SQLite sehingga hanya menangani satu penulisan pada satu waktu.

— Robert Harvey

@ Goyo server tidak diperlukan untuk menangani menulis bersamaan: sebanyak server database merupakan proses yang terpisah, mungkin ada utas terpisah untuk SQLite yang melayani tujuan yang sama. Robert Harvey benar: ada keputusan desain yang dibuat oleh tim SQLite, dan itu tidak ada hubungannya dengan kemampuan perpustakaan tunggal untuk menangani penulisan bersamaan (karena bisa, secara teori).

Jawaban ini sepertinya baik bagi saya. Untuk menangani penulisan bersamaan, tampaknya seseorang harus memiliki server, atau implementasi sqlite multi-utas. Karena keduanya telah dikesampingkan oleh keputusan desain lainnya, mengimplementasikan penulisan bersamaan akan sangat sulit.

— jpa

@ jpa: SQLite berhasil menyinkronkan penguncian antara beberapa proses / utas tanpa "server". "Server" tidak diperlukan - menggunakan penguncian / sinkronisasi yang disediakan OS / IPC / apa pun yang cukup, tetapi menjadi sangat cepat kompleks. "Utas internal" yang disebutkan dalam pos tidak masuk akal.

— Mat