Eventuali duplicati:
What are the performance characteristics of sqlite with very large database files?database con una tabella contenente 700 milioni di dischi
voglio creare un'applicazione .NET che utilizza un database che conterrà circa 700 milioni di dischi in un unico delle sue tabelle. Mi chiedo se le prestazioni di SQLite soddisfino questo scenario o dovrei usare SQL Server. Mi piace la portabilità che mi dà SQLite.
Vai per SQL Server di sicuro. 700 milioni di record in SQLite sono troppi.
Con SQLite hai seguente limitazione
Partenza questa discussione: What are the performance characteristics of sqlite with very large database files?
SQLite dovrebbe essere in grado di gestire questa quantità di dati. Tuttavia, potrebbe essere necessario configurarlo per consentirgli di crescere fino a questa dimensione e non si dovrebbero avere così tanti dati in un'istanza "in memoria" di SQLite, solo su principi generali.
Per ulteriori dettagli, vedere this page che spiega i limiti pratici del motore SQLite. Le impostazioni di configurazione rilevanti sono le dimensioni della pagina (normalmente 64 KB) e il conteggio delle pagine (fino a un valore massimo int di 64 bit di circa 2,1 miliardi). Fai i conti, e l'intero database può occupare più di 140 TB. Un database costituito da una singola tabella con 700 milioni di righe sarebbe dell'ordine di decine di concerti; facilmente gestibile.
Tuttavia, solo perché SQLite PU CAN memorizzare molti dati non significa che DOVREI. Il più grande svantaggio di SQLite per i datastores di grandi dimensioni è che il codice SQLite viene eseguito come parte del processo, utilizzando il thread su cui è chiamato e occupando la memoria nella sandbox. Non si ottengono gli strumenti disponibili nei DBMS orientati al server per "dividere e conquistare" query o archivi di dati di grandi dimensioni, come la replica/clustering. Nell'affrontare una tabella di grandi dimensioni come questa, l'inserimento/eliminazione richiederà molto tempo per inserirlo nel posto giusto e aggiornare tutti gli indici. La selezione PUO essere vivibile, ma solo nelle domande indicizzate; una scansione di una pagina o di una tabella ti ucciderà assolutamente.
Ho avuto tabelle con un numero di record simile e nessun problema di recupero.
Per i principianti, l'hardware e l'assegnazione al server è il punto di partenza. Vedere questo per gli esempi: http://www.sqlservercentral.com/blogs/glennberry/2009/10/29/suggested-max-memory-settings-for-sql-server-2005_2F00_2008/
indipendentemente dalle dimensioni o numero di record come a queste condizioni:
si dovrebbe andare bene. Inoltre, l'impostazione del tipo/dimensione di colonna appropriato per ciascuna colonna aiuterà.
700m è molto.
Per darvi un'idea. Diciamo che la dimensione del tuo record era di 4 byte (essenzialmente memorizzando un singolo valore), quindi il tuo DB supererà i 2 GB. Se la dimensione del tuo record è qualcosa di più vicino a 100 byte, allora è più vicina a 65 GB ... (che non include lo spazio utilizzato dagli indici, i file di registro delle transazioni, ecc.).
Abbiamo fare un sacco di lavoro con grandi database e non avrei mai considerare SqlLite nulla di quelle dimensioni. Francamente, "Portabilità" è l'ultima delle tue preoccupazioni qui. Per poter interrogare un DB di quelle dimensioni con qualsiasi tipo di reattività è necessario un server di database di dimensioni appropriate. Avrei start con 32 GB di RAM e unità veloci.
Se la scrittura è pesante al 90% +, è possibile ottenere una RAM più piccola. Se è pesante, si consiglia di provare a compilarlo in modo che la macchina possa caricare il più possibile il DB (o almeno gli indici) nella RAM. Altrimenti si dipenderà dalla velocità del mandrino del disco.
La portabilità è sopravvalutata. – jason