Quali sono le caratteristiche prestazionali di sqlite con file di database molto grandi? [chiuso]

So che sqlite non funziona bene con file di database estremamente grandi anche quando sono supportati (c'era un commento sul sito Web sqlite che affermava che se hai bisogno di file di dimensioni superiori a 1 GB potresti prendere in considerazione l'uso di un rdbms aziendale. non lo trovi più, potrebbe essere correlato a una versione precedente di sqlite).

Tuttavia, per i miei scopi, vorrei avere un'idea di quanto sia davvero grave prima di prendere in considerazione altre soluzioni.

Sto parlando di file di dati sqlite nell'intervallo multi-gigabyte, da 2 GB in poi. Qualcuno ha qualche esperienza con questo? Qualche consiglio / idea?

Quindi ho fatto alcuni test con sqlite per file molto grandi e sono giunto ad alcune conclusioni (almeno per la mia specifica applicazione).

I test riguardano un singolo file sqlite con una singola tabella o più tabelle. Ogni tabella aveva circa 8 colonne, quasi tutti numeri interi e 4 indici.

L'idea era quella di inserire dati sufficienti fino a quando i file sqlite erano circa 50 GB.

Tavolo singolo

Ho provato a inserire più righe in un file sqlite con una sola tabella. Quando il file era di circa 7 GB (mi dispiace, non posso essere specifico sui conteggi delle righe), gli inserimenti impiegavano troppo tempo. Avevo stimato che il mio test per inserire tutti i miei dati avrebbe richiesto circa 24 ore, ma non è stato completato nemmeno dopo 48 ore.

Questo mi porta a concludere che una singola tabella sqlite molto grande avrà problemi con gli inserimenti e probabilmente anche altre operazioni.

Immagino che questa non sia una sorpresa, poiché la tabella diventa più grande, l'inserimento e l'aggiornamento di tutti gli indici richiedono più tempo.

Tabelle multiple

Ho quindi provato a dividere i dati per tempo su più tabelle, una tabella al giorno. I dati per la 1 tabella originale sono stati divisi in ~ 700 tabelle.

Questa configurazione non ha avuto problemi con l'inserimento, non ha richiesto più tempo con il passare del tempo, poiché una nuova tabella è stata creata per ogni giorno.

Problemi di vuoto

Come sottolineato da i_like_caffeine, il comando VACUUM è un problema più grande è il file sqlite. Man mano che vengono fatti più inserimenti / eliminazioni, la frammentazione del file su disco peggiorerà, quindi l'obiettivo è periodicamente VACUUM per ottimizzare il file e recuperare spazio sul file.

Tuttavia, come sottolineato dalla documentazione , viene creata una copia completa del database per fare il vuoto, impiegando molto tempo per il completamento. Quindi, più piccolo è il database, più veloce sarà questa operazione.

conclusioni

Per la mia specifica applicazione, probabilmente dividerò i dati su più file db, uno al giorno, per ottenere il meglio sia dalle prestazioni del vuoto che dalla velocità di inserimento / cancellazione.

Ciò complica le query, ma per me è un compromesso utile poter indicizzare questi dati. Un ulteriore vantaggio è che posso semplicemente eliminare un intero file db per eliminare i dati di un giorno (un'operazione comune per la mia applicazione).

Probabilmente dovrei monitorare anche le dimensioni della tabella per file per vedere quando la velocità diventerà un problema.

Peccato che non ci sia un metodo di vuoto incrementale diverso dal vuoto automatico . Non posso usarlo perché il mio obiettivo per il vuoto è di deframmentare il file (lo spazio per i file non è un grosso problema), cosa che il vuoto automatico non fa. In effetti, la documentazione afferma che potrebbe peggiorare la frammentazione, quindi devo ricorrere periodicamente al completo vuoto del file.

Stiamo utilizzando DBS di 50 GB + sulla nostra piattaforma. nessuna lamentela funziona alla grande. Assicurati di fare tutto bene! Stai usando istruzioni predefinite? * SQLITE 3.7.3

1. Le transazioni
2. Dichiarazioni pre fatte

3. Applica queste impostazioni (subito dopo aver creato il DB)

   PRAGMA main.page_size = 4096;
   PRAGMA main.cache_size=10000;
   PRAGMA main.locking_mode=EXCLUSIVE;
   PRAGMA main.synchronous=NORMAL;
   PRAGMA main.journal_mode=WAL;
   PRAGMA main.cache_size=5000;
   

Spero che questo possa aiutare gli altri, funziona benissimo qui

Ho creato database SQLite con dimensioni fino a 3,5 GB senza evidenti problemi di prestazioni. Se ricordo bene, penso che SQLite2 avrebbe potuto avere dei limiti inferiori, ma non credo che SQLite3 abbia tali problemi.

Secondo la pagina Limiti SQLite , la dimensione massima di ciascuna pagina del database è 32 KB. E il numero massimo di pagine in un database è 1024 ^ 3. Quindi per la mia matematica che esce a 32 terabyte come dimensione massima. Penso che raggiungerai i limiti del tuo file system prima di colpire quello di SQLite!

Gran parte del motivo per cui ci sono voluti> 48 ore per eseguire gli inserimenti è a causa dei tuoi indici. È incredibilmente più veloce per:

1 - Elimina tutti gli indici 2 - Esegui tutti gli inserti 3 - Crea nuovamente gli indici

Oltre alla solita raccomandazione:

1. Indice di caduta per l'inserimento di massa.
2. Inserimenti / aggiornamenti batch in transazioni di grandi dimensioni.
3. Ottimizza la cache del buffer / disabilita journal / w PRAGMAs.
4. Usa una macchina a 64 bit (per poter usare molta cache ™).
5. [aggiunto luglio 2014] Utilizzare l' espressione di tabella comune (CTE) invece di eseguire più query SQL! Richiede la versione 3.8.3 di SQLite.

Ho imparato quanto segue dalla mia esperienza con SQLite3:

1. Per la massima velocità di inserimento, non utilizzare lo schema con alcun vincolo di colonna. (Modificare la tabella in seguito, se necessario Non è possibile aggiungere vincoli con ALTER TABLE).
2. Ottimizza il tuo schema per archiviare ciò di cui hai bisogno. A volte questo significa scomporre le tabelle e / o persino comprimere / trasformare i dati prima di inserirli nel database. Un ottimo esempio è la memorizzazione degli indirizzi IP come numeri interi (lunghi).
3. Una tabella per file db - per ridurre al minimo i conflitti di blocco. (Utilizzare ATTACH DATABASE se si desidera disporre di un singolo oggetto connessione.
4. SQLite può archiviare diversi tipi di dati nella stessa colonna (tipizzazione dinamica), utilizzarli a proprio vantaggio.

Domanda / commento benvenuto. ;-)

Penso che le principali lamentele sul ridimensionamento di sqlite siano:

1. Scrittura a processo singolo.
2. Nessun mirroring.
3. Nessuna replica.

Ho un database SQLite da 7 GB. Per eseguire una query specifica con un join interno sono necessari 2.6 secondi. Per accelerare ciò, ho provato ad aggiungere indici. A seconda dell'indice o degli indici che ho aggiunto, a volte la query è scesa a 0,1 secondi, a volte fino a 7 secondi. Penso che il problema nel mio caso fosse che se una colonna è altamente duplicata, l'aggiunta di un indice peggiora le prestazioni :(

Nella documentazione di SQLite c'era una dichiarazione secondo cui il limite di dimensioni pratiche di un file di database era di alcune decine di GB: s. Ciò è dovuto principalmente alla necessità che SQLite "alloca una bitmap di pagine sporche" ogni volta che si avvia una transazione. Pertanto erano necessari 256 byte di RAM per ogni MB nel database. L'inserimento in un file DB da 50 GB richiederebbe un pesante (2 ^ 8) * (2 ^ 10) = 2 ^ 18 = 256 MB di RAM.

Ma a partire dalle versioni recenti di SQLite, questo non è più necessario. Leggi di più qui .

Ho riscontrato problemi con file sqlite di grandi dimensioni durante l'utilizzo del comando vacuum.

Non ho ancora provato la funzione auto_vacuum. Se ti aspetti di aggiornare ed eliminare spesso i dati, vale la pena esaminarli.