Bagaimana Scalable adalah SQLite? [Tutup]

178

Saya baru-baru ini membaca Pertanyaan tentang SQLite vs MySQL ini dan jawabannya menunjukkan bahwa SQLite tidak memiliki skala yang baik dan situs resmi semacam ini menegaskan hal ini .

Bagaimana scalable adalah SQLite dan apa batas paling atas?

GateKiller
sumber

Jawaban:

429

Kemarin saya merilis situs kecil *untuk melacak perwakilan Anda yang menggunakan database SQLite bersama untuk semua pengunjung. Sayangnya, bahkan dengan beban sederhana yang diletakkan di host saya itu berjalan cukup lambat. Ini karena seluruh basis data dikunci setiap kali seseorang melihat halaman karena berisi pembaruan / sisipan. Saya segera beralih ke MySQL dan sementara saya tidak punya banyak waktu untuk mengujinya, sepertinya jauh lebih mudah dibandingkan dengan SQLite. Saya hanya ingat memuat halaman lambat dan kadang-kadang mendapatkan kesalahan terkunci basis data ketika mencoba menjalankan query dari shell di sqlite. Yang mengatakan, saya menjalankan situs lain dari SQLite dengan baik. Perbedaannya adalah bahwa situs ini statis (yaitu saya satu-satunya yang dapat mengubah database) dan itu berfungsi dengan baik untuk dibaca bersamaan. Pesan moral dalam cerita:

sunting : Saya baru menyadari bahwa saya mungkin tidak adil terhadap SQLite - saya tidak mengindeks kolom apa pun di database SQLite ketika saya menyajikannya dari halaman web. Ini sebagian menyebabkan perlambatan yang saya alami. Namun, pengamatan terhadap penguncian basis data - jika Anda memiliki pembaruan yang sangat berat, kinerja SQLite tidak akan cocok dengan MySQL atau Postgres.

suntingan lain: Sejak saya memposting ini hampir 3 bulan yang lalu saya memiliki kesempatan untuk memeriksa skalabilitas SQLite, dan dengan beberapa trik itu bisa sangat scalable. Seperti yang saya sebutkan di edit pertama saya, indeks basis data secara dramatis mengurangi waktu permintaan, tetapi ini lebih merupakan pengamatan umum tentang database daripada tentang SQLite. Namun, ada trik lain yang dapat Anda gunakan untuk mempercepat SQLite: transaksi . Setiap kali Anda harus menulis banyak database, letakkan di dalam transaksi. Alih-alih menulis untuk (dan mengunci) file masing-masing dan setiap kali kueri menulis dikeluarkan, penulisan hanya akan terjadi sekali ketika transaksi selesai.

Situs yang saya sebutkan saya rilis di paragraf pertama telah beralih kembali ke SQLite, dan itu berjalan cukup lancar setelah saya mencari kode saya di beberapa tempat.

* situs tidak lagi tersedia

Kyle Cronin
sumber
3
Mesin database "klasik" MySQL, MyISAM, memiliki masalah yang sama mengenai operasi baca / tulis bersamaan dengan SQLite. Bahkan, ia mengunci setiap baris yang disentuhnya dalam operasi tulis, sehingga tidak mungkin untuk skala aplikasi intensif. Tetap saja, ia melayani banyak aplikasi web dengan baik.
Henning
1
Bisakah Anda menulis ulang awal jawaban Anda? Menilai kinerja DB tanpa indeks yang tepat sama sekali tidak adil. Transaksi juga banyak mengubah kinerja dan skalabilitas SQLite.
Kornel
3
@porneL: Benar, tetapi SQLite tanpa indeks adalah urutan besarnya lebih lambat dari MySQL tanpa indeks, dan saya juga memasukkan sedikit tentang transaksi dalam edit kedua saya. Saya masih berpikir bahwa perkembangan jawaban itu masuk akal - ini menunjukkan penggunaan awal saya yang naif terhadap SQLite dan seberapa buruk kinerjanya. Saya berharap bahwa mereka yang baru ke platform akan menghadapi masalah yang sama, dan saya berharap mereka dapat mengidentifikasi dengan paragraf pertama, kemudian membaca suntingan berikut dan menyadari bahwa ada cara mempercepat SQLite untuk memiliki kinerja yang dapat diterima.
Kyle Cronin
1
Bisakah Anda berbagi dengan kami tentang berapa banyak hit per detik yang didapat situs Anda?
NoobOverflow
2
Ada juga write-ahead-logging (WAL) yang tersedia dalam versi SQLite yang lebih baru yang dapat menghilangkan beberapa rasa sakit dari siklus baca / tulis. Banyak hal berubah.
Lasse V. Karlsen
58

Sqlite dapat diukur dalam hal pengguna tunggal, saya memiliki basis data multi-gigabyte yang berkinerja sangat baik dan saya tidak punya banyak masalah dengannya.

Tapi ini adalah pengguna tunggal, jadi itu tergantung pada skala apa yang sedang Anda bicarakan.

Menanggapi komentar. Perhatikan bahwa tidak ada yang mencegah menggunakan database Sqlite di lingkungan multi-pengguna, tetapi setiap transaksi (pada dasarnya, setiap pernyataan SQL yang memodifikasi database) mengambil kunci pada file , yang akan mencegah pengguna lain mengakses database di semua .

Jadi, jika Anda memiliki banyak modifikasi yang dilakukan pada database, Anda pada dasarnya akan mencapai masalah penskalaan dengan sangat cepat. Sebaliknya, jika Anda memiliki banyak akses baca dibandingkan akses tulis, itu mungkin tidak terlalu buruk.

Tapi tentu saja Sqlite akan berfungsi dalam lingkungan multi-pengguna, tetapi tidak akan bekerja dengan baik.

Lasse V. Karlsen
sumber
5
SQLite 3 mendukung pembacaan ketika pengguna lain menulis untuk itu.
Alix Axel
2
Perhatikan bahwa komentar di atas ketinggalan zaman, dengan sistem WAL (er) baru, menulis dan membaca dapat dilakukan pada saat yang sama, meningkatkan skalabilitas.
Lasse V. Karlsen
Apakah mungkin membuat untuk mengekspor catatan dengan cepat ke sqlite dari rdbms seperti sql server atau oracle dll?
ILoveStackoverflow
29

SQLite menggerakkan situs web sqlite.org dan lainnya yang memiliki banyak lalu lintas. Mereka menyarankan bahwa jika Anda memiliki kurang dari 100 ribu hit per hari, SQLite akan berfungsi dengan baik. Dan itu ditulis sebelum mereka memberikan fitur "Writeahead Logging".

Jika Anda ingin mempercepat dengan SQLite, lakukan hal berikut:

  • tingkatkan ke SQLite 3.7.x
  • Aktifkan pencatatan menulis-depan
  • Jalankan pragma berikut: "PRAGMA cache_size = Jumlah halaman;" Ukuran default (Jumlah halaman) adalah 2000 halaman, tetapi jika Anda meningkatkan angka itu, maka Anda akan meningkatkan jumlah data yang berjalan langsung kehabisan memori.

Anda mungkin ingin melihat video saya di YouTube yang disebut " Tingkatkan Kinerja SQLite dengan Writeahead Logging " yang menunjukkan cara menggunakan logging penulisan-depan dan menunjukkan peningkatan kecepatan 5x untuk menulis.

Jay Godse
sumber
24

Sqlite adalah database desktop atau dalam proses . SQL Server, MySQL, Oracle, dan saudara-saudara mereka adalah server .

Database desktop pada dasarnya bukan pilihan yang baik untuk aplikasi apa pun yang perlu mendukung akses tulis bersamaan ke penyimpanan data. Ini termasuk pada tingkat tertentu sebagian besar situs web yang pernah dibuat. Jika Anda bahkan harus login untuk apa pun, Anda mungkin perlu akses tulis ke DB.

Joel Coehoorn
sumber
5
Saya tidak setuju dengan 'Ini termasuk hampir semua situs web yang pernah dibuat.' komentar. Jika situs web memuat banyak, Anda benar. Trac misalnya menggunakan SQLite secara default dan berkinerja sangat baik di luar kotak untuk tim kecil.
Andrew Burns
2
Beri waktu: Anda akan memiliki dua pengembang mengakses bidang yang sama secara bersamaan dan itu akan tersedak.
Joel Coehoorn
3
Apa yang Anda definisikan sebagai tersedak? dari tanggapan Anda, saya kira Anda tidak memiliki banyak pengalaman dengan SQLite. SQLite akan mengunci seluruh file pada operasi sehingga Anda mungkin mengalami penundaan, tetapi hampir tidak mungkin untuk membuatnya 'tersedak' dalam situasi yang Anda usulkan.
Andrew Burns
3
Andrew, karena SQL Lite bekerja dengan baik untuk tim kecil, tidak membuatnya scalable, untuk scalable persyaratannya baik untuk skala, artinya harus berkinerja baik dengan tim besar. Setahu saya SQL Lite tidak dapat diskalakan untuk tim besar / operasi database bersamaan yang melebihi ambang batas yang cukup rendah.
Pop Catalin
5
@Keadilan. Jawaban ini tidak memiliki bukti yang mendukung tentang bagaimana SQLite scalable. Jawaban oleh siapa pun jauh lebih baik.
GateKiller
23

Sudahkah Anda membaca dokumen SQLite ini - http://www.sqlite.org/whentouse.html ?

SQLite biasanya akan bekerja dengan baik sebagai mesin basis data untuk situs web dengan lalu lintas rendah hingga sedang (artinya, 99,9% dari semua situs web). Jumlah lalu lintas web yang dapat ditangani oleh SQLite tergantung, tentu saja, pada seberapa banyak situs web menggunakan database-nya. Secara umum, situs apa pun yang mendapat kurang dari 100 ribu hit / hari harus berfungsi baik dengan SQLite. Angka 100 ribu / hari adalah perkiraan konservatif, bukan batas atas yang sulit. SQLite telah terbukti bekerja dengan 10 kali jumlah traffic.

Sam
sumber
3
Saya sangat setuju dengan ini. 99% situs web dapat ditangani dengan SQLLite jika Anda mau. Namun, 99% dari lalu lintas web pergi ke 1% situs web terbesar, di sisi lain.
djangofan
7
Metrik "hit 100k / hari" adalah sampah total. "Hit" biasanya didefinisikan sebagai GET HTTP dan situs web dengan banyak gambar yang diiris mungkin mendapatkan 40+ "klik" per tampilan halaman - tidak ada yang menyentuh DB. Bahkan jika dokumen membuat kesalahan klik == tampilan halaman, itu masih menyesatkan. SQLite mengunci seluruh DB pada penulisan. Meskipun dapat melayani 100r tampilan halaman dengan gagah berani dari orang yang hanya menelusuri catatan, itu akan berantakan dalam aplikasi intensif (e-commerce, papan pesan, dll).
jamieb
10

Skalabilitas SQLite akan sangat tergantung pada data yang digunakan, dan formatnya. Saya memiliki pengalaman yang sulit dengan tabel ekstra panjang (catatan GPS, satu catatan per detik). Pengalaman menunjukkan bahwa SQLite akan melambat secara bertahap, sebagian karena penyeimbangan ulang terus-menerus dari pohon biner yang tumbuh yang menahan indeks (dan dengan indeks waktu, Anda hanya tahu bahwa pohon akan mendapatkan banyak penyeimbangan kembali, namun sangat penting bagi Anda pencarian). Jadi pada akhirnya sekitar 1GB (sangat kasar, saya tahu), pertanyaan menjadi lamban dalam kasus saya. Jarak tempuh Anda akan bervariasi.

Satu hal yang perlu diingat, meskipun semua membual, SQLite TIDAK dibuat untuk data warehousing. Ada berbagai kegunaan yang tidak disarankan untuk SQLite. Orang-orang baik di belakang SQLite mengatakannya sendiri:

Cara lain untuk melihat SQLite adalah ini: SQLite tidak dirancang untuk menggantikan Oracle. Ini dirancang untuk menggantikan fopen ().

Dan ini mengarah pada argumen utama (bukan kuantitatif, maaf, tapi kualitatif), SQLite tidak untuk semua penggunaan, sedangkan MySQL dapat mencakup banyak kegunaan yang beragam, bahkan jika tidak idealnya. Misalnya, Anda dapat memiliki MySQL yang menyimpan cookie Firefox (bukan SQLite), tetapi Anda akan membutuhkan layanan itu berjalan sepanjang waktu. Di sisi lain, Anda bisa membuat situs web transaksional berjalan di SQLite (seperti banyak orang), bukan MySQL, tetapi mengharapkan banyak downtime.

MPelletier
sumber
1
Anda dapat mengatasi masalah memiliki tabel indeks yang sangat besar dengan membagikan data Anda, misalnya satu tabel per hari / minggu. SQLite bahkan memungkinkan Anda untuk membagi tabel menjadi file database yang berbeda dan kemudian gunakan ATTACH DATABASEuntuk membuat koneksi database virtual dengan semua tabel (namun terbatas pada 62 basis data).
Alix Axel
3

Saya berpikir bahwa (dalam angka 1) server web yang melayani hunderts klien muncul di backend dengan satu koneksi ke database, bukan?

Jadi tidak ada akses bersamaan dalam database dan oleh karena itu kita dapat mengatakan bahwa database bekerja dalam 'mode pengguna tunggal'. Tidak masuk akal untuk menghentikan akses multi-pengguna dalam keadaan seperti itu dan SQLite berfungsi serta database berbasis server lainnya.

Es
sumber
1
Thx GateKiller, tapi tolong sebutkan "situs web volume rendah".
Ice
3

Pikirkan seperti ini. SQL Lite akan dikunci setiap kali seseorang menggunakannya (SQLite tidak mengunci saat membaca). Jadi jika Anda menyajikan halaman web atau aplikasi yang memiliki banyak pengguna secara bersamaan, hanya satu yang dapat menggunakan aplikasi Anda sekaligus dengan SQLLite. Jadi ada masalah penskalaan. Jika aplikasi satu orang mengatakan Perpustakaan Musik di mana Anda memegang ratusan judul, peringkat, informasi, penggunaan, bermain, waktu bermain maka SQL Lite akan skala indah memegang ribuan jika tidak jutaan catatan (Hard drive bersedia)

MySQL di sisi lain bekerja dengan baik untuk aplikasi server di mana orang-orang di seluruh dunia akan menggunakannya secara bersamaan. Itu tidak mengunci dan ukurannya cukup besar. Jadi untuk perpustakaan musik Anda MySql akan lebih dari membunuh karena hanya satu orang yang akan melihatnya, KECUALI ini adalah perpustakaan musik bersama di mana ribuan menambahkan atau memperbaruinya. Maka MYSQL yang akan digunakan.

Jadi secara teori MySQL memiliki skala yang lebih baik daripada Sqllite karena dapat menangani beberapa pengguna, tetapi terlalu banyak untuk satu aplikasi pengguna.

dr luar negeri
sumber
5
s / gunakan / tulis untuk itu. sqlite tidak mengunci saat dibaca.
Gregg Lind
5
baik, jawaban Anda dapat disalahartikan dengan mudah. SQLite mengunci permintaan tulis saja . Kami menggunakan SQLite dengan data medis lebih dari 50GB dalam bentuk relasional dan melayani ratusan klien web simultan untuk penelusuran dan permintaan. Performanya membaca tidak pernah lebih buruk daripada MySQL baru.
Berk D. Demir
3
MyISAM MySQL tidak jauh lebih baik untuk akses bersamaan dari SQLite. MySQL banyak menggunakan kunci tingkat tabel, dan tidak akan melakukan penulisan bersamaan kecuali dalam beberapa kasus di mana tata letak MyISAM optimal. Kecuali Anda menggunakan InnoDB (yang memiliki masalah sendiri seperti datafile yang tidak pernah menyusut), Anda mungkin tidak jauh lebih baik dengan MySQL.
Kornel
1

Situs web SQLite (bagian yang Anda referensikan) menunjukkan bahwa itu dapat digunakan untuk berbagai situasi multi-pengguna.

Saya akan mengatakan bahwa itu dapat menangani sedikit. Dalam pengalaman saya selalu sangat cepat. Tentu saja, Anda perlu mengindeks tabel Anda dan ketika mengkodekannya, Anda harus memastikan bahwa Anda menggunakan kueri yang diparematisasi dan sejenisnya. Pada dasarnya hal yang sama akan Anda lakukan dengan basis data apa pun untuk meningkatkan kinerja.

jle
sumber
dan gunakan transaksi. Itu penting untuk SQLite.
Kornel
-1

Mungkin perlu memeriksa REAL SQL Server , yang merupakan server basis data yang dibangun di atas SQLite.

Paul Lefebvre
sumber
7
Saya tidak berpikir situs mana pun mengeluarkan biaya $ 299 untuk "NYATA SQL Server" ketika sebagian besar situs tidak mendapatkan lalu lintas yang cukup untuk bahkan mulai mencapai batas SQLLite.
djangofan