Apa itu ukuran maksimum realistis, dunia nyata, maksimum untuk database SQLite?

Menurut artikel ini tentang Penggunaan yang Sesuai Untuk SQLite dikatakan bahwa, sementara SQLite terbatas hingga 140 terabyte , RDBMS klien / server dapat bekerja lebih baik:

Database SQLite terbatas dalam ukuran hingga 140 terabyte (2 ⁴⁷ byte, 128 tibibytes). Dan bahkan jika itu bisa menangani database yang lebih besar, SQLite menyimpan seluruh database dalam file disk tunggal dan banyak sistem file membatasi ukuran maksimum file untuk sesuatu yang kurang dari ini. Jadi jika Anda merenungkan basis data sebesar ini, sebaiknya Anda mempertimbangkan untuk menggunakan mesin basis data klien / server yang menyebar kontennya ke beberapa file disk, dan mungkin di beberapa volume.

Secara umum, saya setuju dengan ini, tetapi saya terkejut mengetahui bahwa batas maksimum SQLite sangat tinggi! Dalam pengalaman saya, saya telah menggunakan beberapa database SQL Server dalam ukuran ~ 30-100GB. Saya juga telah bekerja secara tidak langsung dengan database yang jauh lebih besar menggunakan Oracle, Postgres, atau Cassandra. Dari mereka, setidaknya setahu saya, tidak ada yang mendekati 140TB. Saya bukan DBA, jadi ini yang saya anggap "besar" dari pengalaman langsung saya.

Saya hanya mempertimbangkan SQLite untuk situasi di mana basis data akan menjadi kecil; lusinan megabita paling banyak.

Setelah membaca artikel ini, saya masih belum yakin untuk mempertimbangkan SQLite untuk apa pun yang mungkin membutuhkan ratusan gigabytes. Tapi saya bertanya-tanya apakah saya telah meremehkan kemampuannya. Apa batas maksimum ukuran maks untuk database SQLite yang digunakan di dunia nyata?

Batas realistis (dari ukuran beberapa basis data Sqlite) sama dengan batas realistis untuk file data. Dan batas itu sangat tergantung pada komputer & sistem Anda. Pada desktop Linux saya saat ini, saya tidak mampu membeli file berukuran lebih besar dari 350Gbyte (karena pada dasarnya saya menghindari satu file tunggal yang memakan lebih dari setengah partisi disk). BTW, batas praktis itu juga berdampak pada RDBMS SQL lainnya seperti PostGreSQL atau MariaDB (tetapi sebagian besar menyimpan data dalam beberapa file, yang mungkin Anda simpan pada sistem file yang berbeda, dan beberapa di antaranya mampu mengelola data terdistribusi pada mesin jarak jauh .. .)

Setelah membaca artikel ini, saya masih belum yakin untuk mempertimbangkan SQLite untuk apa pun yang mungkin membutuhkan ratusan gigabyte

Anda benar dan salah.

Anda benar, karena pada komputer saat ini (laptop & desktop, bukan superkomputer atau server pusat data), seratus gigabyte masih merupakan ruang disk yang cukup besar. Jadi dalam praktiknya, jika Anda memikirkan basis data yang begitu besar, lebih baik Anda membayangkan server SQL yang nyata (à la PostGreSQL) khususnya karena Anda mungkin menginginkan akses jarak jauh, akses bersamaan yang efektif dan mungkin data & tabel yang didistribusikan.

Anda (pada prinsipnya, saya tidak pernah mencoba) salah karena sangat mungkin SQLite mampu (dan kadang-kadang diuji) untuk berurusan dengan database beberapa ratus gigabyte, dengan asumsi Anda memiliki sistem file yang mampu menangani file sebesar itu (dan mungkin dua dari setidaknya mereka).

Saya pasti akan (kadang-kadang) mempertimbangkan SQLite untuk database beberapa lusin gigabytes (dan saya memang pernah mencoba .sqlitefile sebesar itu , IIRC sebesar 40Gbytes). Pada komputer saat ini (non-superkomputer), saya akan ragu memiliki ratusan gigabytes basis data SQLite, hanya karena file seperti itu cukup besar oleh praktik saat ini.

IIRC beberapa vendor perangkat keras yang menjual mesin sistem file khusus memang pernah berbicara kepada saya tentang aplikasi sqlite terabyte (tapi saya bisa saja salah).

Tentu saja kinerja SQLite tergantung (seperti semua database SQL) banyak dari jumlah dan lebar tabel, indeks mereka, query SQL yang terlibat. Dan Anda tidak ingin memiliki akses simultan (dengan banyak proses berbeda), dan Anda harus menggunakan transaksi (berdasarkan pengalaman, bahkan pada basis data SQLITE kecil beberapa megabyte, Anda benar-benar ingin membungkus mis. Ribuan permintaan penyisipan Anda dengan BEGIN TRANSACTION& END TRANSACTION, tidak melakukan itu memperlambat Sqlite dengan faktor besar -lebih dari 10x-).

Dan berdasarkan pengalaman pribadi, dengan konfigurasi dan pengaturan yang sesuai, SQLite mampu mengelola basis data yang lebih besar dari RAM yang tersedia (jadi 30Gbytes bukan masalah) - tetapi Anda mungkin menginginkan indeks sesuai dengan RAM!

Jika Anda kebetulan membuat kode untuk "superkomputer" atau workstation yang mahal (misalnya, misalnya 512Gbytes RAM dan 8Tbytes disk dan 512Gbyte SSD), Anda tentu dapat memiliki database Sqlite terabyte. Tetapi Anda ingin melakukannya mungkin hanya jika satu (atau sangat sedikit) proses mengakses database itu. Jika Anda memiliki selusin proses mengakses bersamaan database yang sama, lebih baik instal RDBMS SQL nyata (à la MariaDB atau PostGreSQL)

Juga perhatikan bahwa sementara format (biner) dari .sqlitefile database didokumentasikan sebagai "portable", saya lebih suka untuk membuat cadangan database dalam format tekstual SQL (menggunakan sqlite3 mydb.sqlite .dump > mydb.sql). Kemudian, saya juga memerlukan beberapa ruang disk tambahan untuk dump teks (dan yang menurunkan batas realistis).

Biasanya Sqlite bukanlah hambatannya. Tetapi disk mungkin.

PS. Alasan yang sama bisa diterapkan pada file besar yang diindeks menggunakan GDBM .

^{PPS. Di cabang expjs saya (sept.2016) dari monitor MELT saya (perangkat lunak bebas GPLv3, di github) saya bertahan seluruh aplikasi menumpuk di JSON di dalam database Sqlite yang baru. Saya telah menjalankan eksperimen kecil dengan jutaan objek (cukup "besar") tanpa kejutan buruk. YMMV.}