Che cos'è una dimensione massima realistica, reale, per un database SQLite?

Secondo questo articolo sugli usi appropriati di SQLite, si dice che, sebbene SQLite sia limitato a 140 terabyte , un RDBMS client / server potrebbe funzionare meglio:

Un database SQLite ha dimensioni limitate a 140 terabyte (2 ⁴⁷ byte, 128 tibibyte). E anche se fosse in grado di gestire database più grandi, SQLite archivia l'intero database in un singolo file su disco e molti filesystem limitano la dimensione massima dei file a qualcosa di meno. Quindi, se stai pensando a database di questa portata, faresti bene a considerare l'uso di un motore di database client / server che diffonde il suo contenuto su più file su disco e forse su più volumi.

In generale, sono d'accordo con questo, ma sono stato sorpreso di apprendere che il limite massimo di SQLite era così alto! Nella mia esperienza ho usato alcuni database di SQL Server con dimensioni di ~ 30-100 GB. Ho anche lavorato indirettamente con database molto più grandi usando Oracle, Postgres o Cassandra. Di quelli, almeno per quanto ne so, nessuno si avvicinava a 140 TB. Non sono un DBA, quindi questo è ciò che considererei "ampio" dalla mia esperienza diretta.

Ho considerato SQLite solo per situazioni in cui il database sarebbe minuscolo; dozzine di megabyte al massimo.

Dopo aver letto questo articolo non sono ancora convinto di prendere in considerazione SQLite per tutto ciò che potrebbe richiedere centinaia di gigabyte. Ma mi chiedo se ho sottovalutato le sue capacità. Qual è un limite di dimensione massima realistico per un database SQLite nell'uso reale?

Il limite realistico (della dimensione di alcuni database Sqlite) è lo stesso del limite realistico per un file di dati. E quel limite dipende molto dal tuo computer e sistema. Sul mio attuale desktop Linux non posso permettermi molto più grande di un file da 350 Gbyte (perché come regola generale evito di avere un singolo file che consuma più di mezza partizione del disco). A proposito, quel limite pratico influisce anche su altri RDBMS SQL come PostGreSQL o MariaDB (ma la maggior parte di questi conserva i dati in diversi file, che è possibile conservare su file system diversi, e alcuni di essi sono in grado di gestire i dati distribuiti su macchine remote. .)

Dopo aver letto questo articolo non sono ancora convinto di prendere in considerazione SQLite per tutto ciò che potrebbe richiedere centinaia di gigabyte

Hai ragione e torto.

Hai ragione, perché sul computer di oggi (laptop e desktop, non supercomputer o server di datacenter), un centinaio di gigabyte è ancora uno spazio su disco abbastanza grande. Quindi, in pratica, se si pensa a un database così grande, è meglio immaginare un vero server SQL (alla PostGreSQL) in particolare perché si potrebbe desiderare molto probabilmente un accesso remoto, un accesso simultaneo efficacemente e probabilmente dati e tabelle distribuiti.

Ti sbagli (in linea di principio, non ho mai provato) perché molto probabilmente SQLite è in grado (e talvolta testato) di gestire un database di diverse centinaia di gigabyte, supponendo che tu abbia un filesystem in grado di gestire un file così grande (e probabilmente due di almeno loro).

Certamente (a volte) prenderei in considerazione SQLite per database di diverse dozzine di gigabyte (e ho provato una volta un .sqlitefile così grande , IIRC di 40 Gbyte). Su macchine attuali (non supercomputer), esiterei ad avere centinaia di gigabyte di database SQLite, semplicemente perché un tale file è abbastanza grande per la pratica di oggi.

IIRC alcuni venditori di hardware che vendono macchine specializzate per filesystem mi hanno parlato una volta di un'applicazione sqlite terabyte (ma potrei sbagliarmi).

Ovviamente le prestazioni di SQLite dipendono (come tutti i database SQL) da gran parte del numero e della larghezza delle tabelle, dei loro indici, delle query SQL coinvolte. E non vuoi avere accesso simultaneo (attraverso molti processi diversi) e dovresti usare la transazione (per esperienza, anche su un piccolo database SQLITE di pochi megabyte, vuoi davvero avvolgere le tue migliaia di richieste di inserimento con BEGIN TRANSACTION& END TRANSACTION, non farlo significa rallentare Sqlite di un grande fattore -più di 10x-).

E per esperienza personale, con una configurazione e un'organizzazione adeguate, SQLite è in grado di gestire un database più grande della RAM disponibile (quindi 30 Gbyte non è un problema) - ma probabilmente vuoi che gli indici si adattino alla RAM!

Se ti capita di codificare qualcosa per un "supercomputer" o una costosa workstation (con ad esempio 512 Gbyte di RAM e 8 Tbyte di disco e 512 Gbyte di SSD) puoi sicuramente avere un database Sqlite terabyte. Ma ti consigliamo di farlo forse solo se uno (o pochissimi) processi accedono a quel database. Se hai una dozzina di processi che accedono contemporaneamente allo stesso database, installa meglio un RDBMS SQL reale (alla MariaDB o PostGreSQL)

Si noti inoltre che mentre il formato (binario) dei .sqlitefile di database è documentato come "portatile", preferisco di gran lunga fare il backup dei database in formato testuale SQL (usando sqlite3 mydb.sqlite .dump > mydb.sql). Quindi, ho anche bisogno di spazio su disco aggiuntivo per quel dump testuale (e questo abbassa il limite realistico).

Di solito Sqlite non è il collo di bottiglia. Ma il disco potrebbe essere.

PS. Lo stesso ragionamento potrebbe essere applicato a file indicizzati di grandi dimensioni utilizzando GDBM .

^{PPS. Nel mio ramo expjs ( settembre 2016 ) del mio monitor MELT (software gratuito GPLv3, su github) sto persistendo l'intero heap dell'applicazione in JSON all'interno di un nuovo database Sqlite. Ho condotto piccoli esperimenti con diversi milioni di oggetti (abbastanza "grandi") senza brutte sorprese. YMMV.}