Quanto è scalabile SQLite? [chiuso]


178

Di recente ho letto questa domanda su SQLite vs MySQL e la risposta ha sottolineato che SQLite non si adatta bene e il sito Web ufficiale lo conferma comunque.

Quanto è scalabile SQLite e quali sono i suoi limiti più alti?

Risposte:


429

Ieri ho pubblicato un piccolo sito *per tenere traccia del rappresentante che ha utilizzato un database SQLite condiviso per tutti i visitatori. Sfortunatamente, anche con il carico modesto che ha messo sul mio host ha funzionato abbastanza lentamente. Questo perché l'intero database è stato bloccato ogni volta che qualcuno visualizzava la pagina perché conteneva aggiornamenti / inserimenti. Passai presto a MySQL e, sebbene non abbia avuto molto tempo per testarlo, sembra molto più scalabile di SQLite. Ricordo solo il lento caricamento della pagina e occasionalmente il verificarsi di un errore di blocco del database durante il tentativo di eseguire query dalla shell in sqlite. Detto questo, sto eseguendo un altro sito da SQLite bene. La differenza è che il sito è statico (cioè sono l'unico che può cambiare il database) e quindi funziona bene per letture simultanee. Morale della storia:

modifica : mi sono appena reso conto che potrei non essere stato corretto con SQLite - non ho indicizzato nessuna colonna nel database SQLite quando lo stavo servendo da una pagina web. Ciò ha parzialmente causato il rallentamento che stavo vivendo. Tuttavia, l'osservazione dei blocchi del database si blocca: se si dispone di aggiornamenti particolarmente onerosi, le prestazioni di SQLite non corrisponderanno a MySQL o Postgres.

un'altra modifica: da quando l'ho pubblicato quasi 3 mesi fa ho avuto l'opportunità di esaminare attentamente la scalabilità di SQLite e con alcuni trucchi può essere abbastanza scalabile. Come ho accennato nella mia prima modifica, gli indici dei database riducono drasticamente i tempi delle query, ma si tratta più di un'osservazione generale sui database che di SQLite. Tuttavia, c'è un altro trucco che puoi usare per velocizzare SQLite: le transazioni . Ogni volta che devi fare più scritture di database, inseriscile in una transazione. Invece di scrivere (e bloccare) il file ogni volta che viene emessa una query di scrittura, la scrittura avverrà solo una volta al termine della transazione.

Il sito che ho citato di aver pubblicato nel primo paragrafo è tornato a SQLite, e funziona abbastanza bene dopo aver modificato il mio codice in alcuni punti.

* il sito non è più disponibile


3
Il motore di database "classico" di MySQL, MyISAM, presenta gli stessi problemi relativi alle operazioni di lettura / scrittura simultanee di SQLite. In effetti, blocca ogni singola riga che tocca in un'operazione di scrittura, rendendo impossibile ridimensionare le applicazioni ad alta intensità di scrittura. Tuttavia, ha funzionato bene con molte applicazioni web.
Henning,

1
Potresti riscrivere l'inizio della tua risposta allora? Giudicare le prestazioni di DB senza indici appropriati è completamente ingiusto. Anche le transazioni cambiano molto le prestazioni e la scalabilità di SQLite.
Kornel,

3
@porneL: Vero, ma SQLite senza indici era un ordine di grandezza più lento di MySQL senza indici, e ho anche incluso un po 'di transazioni nella mia seconda modifica. Penso ancora che la progressione della risposta abbia un senso: mostra il mio uso ingenuo iniziale di SQLite e quanto sia stata relativamente negativa la prestazione. Mi aspetto che i nuovi arrivati ​​sulla piattaforma incontrino problemi simili e spero che possano identificarsi con il primo paragrafo, quindi leggere le modifiche seguenti e rendersi conto che ci sono modi per accelerare SQLite per ottenere prestazioni accettabili.
Kyle Cronin,

1
Potete per favore condividere con noi approssimativamente quanti hit al secondo sta ottenendo il vostro sito?
NoobOverflow,

2
Sono inoltre disponibili WAL (write-ahead-logging) nelle versioni SQLite più recenti che possono eliminare alcune delle problematiche legate ai cicli di lettura / scrittura. Le cose cambiano.
Lasse V. Karlsen,

58

Sqlite è scalabile in termini di utente singolo, ho un database multi-gigabyte che funziona molto bene e non ho avuto molti problemi con esso.

Ma è monoutente, quindi dipende dal tipo di ridimensionamento di cui stai parlando.

In risposta ai commenti. Si noti che non esiste nulla che impedisca l'utilizzo di un database Sqlite in un ambiente multiutente, ma ogni transazione (in effetti, ogni istruzione SQL che modifica il database) blocca il file , impedendo ad altri utenti di accedere al database in tutto .

Quindi, se hai apportato molte modifiche al database, essenzialmente colpirai i problemi di ridimensionamento molto rapidamente. Se, d'altra parte, hai un sacco di accesso in lettura rispetto all'accesso in scrittura, potrebbe non essere così male.

Ma Sqlite sarà ovviamente la funzione in un ambiente multi-utente, ma sarà non svolgere bene.


5
SQLite 3 supporta la lettura quando altri utenti ci scrivono.
Alix Axel,

2
Si noti che i commenti di cui sopra sono obsoleti, con il nuovo sistema (er) WAL, è possibile eseguire contemporaneamente scritture e letture, aumentando la scalabilità.
Lasse V. Karlsen,

È possibile creare per esportare record al volo su sqlite da qualsiasi rdbms come SQL Server o Oracle ecc?
ILoveStackoverflow,

29

SQLite guida il sito Web sqlite.org e altri che hanno molto traffico. Suggeriscono che se hai meno di 100.000 accessi al giorno, SQLite dovrebbe funzionare bene. E questo è stato scritto prima che offrissero la funzione "Writeahead Logging".

Se vuoi velocizzare le cose con SQLite, procedi come segue:

  • eseguire l'aggiornamento a SQLite 3.7.x
  • Abilita la registrazione write-ahead
  • Esegui il seguente pragma: "PRAGMA cache_size = Numero di pagine;" La dimensione predefinita (Numero di pagine) è di 2000 pagine, ma se aumenti quel numero, aumenterai la quantità di dati che sta per esaurire la memoria.

Potresti dare un'occhiata al mio video su YouTube chiamato " Migliora le prestazioni di SQLite con la registrazione di Writeahead " che mostra come utilizzare la registrazione in scrittura e dimostra un miglioramento della velocità 5x per le scritture.


24

Sqlite è un database desktop o in-process . SQL Server, MySQL, Oracle e i loro fratelli sono server .

I database desktop non sono per loro natura una buona scelta per qualsiasi applicazione che debba supportare l'accesso in scrittura simultanea all'archivio dati. Ciò include a un certo livello la maggior parte dei siti Web mai creati. Se devi effettuare l'accesso per qualsiasi cosa, probabilmente avrai bisogno dell'accesso in scrittura al DB.


5
Non sarei d'accordo con "Questo include praticamente ogni sito web mai creato". commento. Se il sito Web ha un carico elevato, hai ragione. Trac, ad esempio, utilizza SQLite per impostazione predefinita e offre prestazioni ottimali per i piccoli team.
Andrew Burns,

2
Dagli tempo: avrai due sviluppatori che accederanno allo stesso campo contemporaneamente e si strozzerà.
Joel Coehoorn,

3
Cosa definisci soffocare? dalla tua risposta suppongo che tu non abbia molta esperienza con SQLite. SQLite bloccherà l'intero file durante le operazioni, pertanto potresti riscontrare un ritardo, ma è quasi impossibile averlo "soffocato" nella situazione proposta.
Andrew Burns,

3
Andrew, poiché SQL Lite funziona bene per i piccoli team, non lo rende scalabile, per scalare il requisito è ben ridimensionabile, il che significa che dovrebbe funzionare bene con i team di grandi dimensioni. Per quanto ne so, SQL Lite non è scalabile per team di grandi dimensioni / operazioni di database simultanee che superano una soglia abbastanza bassa.
Pop Catalin,

5
@Giustizia. Questa risposta non ha prove a sostegno di quanto sia scalabile SQLite. La risposta di nessuno è molto migliore.
GateKiller,

23

Hai letto questo documento SQLite - http://www.sqlite.org/whentouse.html ?

SQLite di solito funziona alla grande come motore di database per siti Web a traffico medio-basso (vale a dire, il 99,9% di tutti i siti Web). La quantità di traffico Web che SQLite è in grado di gestire dipende, ovviamente, da quanto pesantemente il sito Web utilizza il suo database. In generale, qualsiasi sito che ottiene meno di 100.000 visite / giorno dovrebbe funzionare correttamente con SQLite. La cifra di 100K hit / giorno è una stima prudente, non un limite superiore rigido. È stato dimostrato che SQLite funziona con una quantità di traffico 10 volte superiore.


3
Sono molto d'accordo con questo. Se lo si desidera, il 99% dei siti Web potrebbe essere gestito correttamente con SQLLite. D'altra parte, il 99% del traffico web arriva al più grande 1% di siti Web.
Djangofan,

7
La metrica di "100k hit / giorno" è immondizia totale. Un "hit" è in genere definito come HTTP GET e un sito Web con un sacco di immagini suddivise potrebbe ottenere oltre 40 "hit" per visualizzazione di pagina, nessuna delle quali tocca il DB. Anche se i documenti stanno commettendo l'errore di hit == pageview, è ancora fuorviante. SQLite blocca l'intero DB su una scrittura. Mentre può servire valorosamente 100k visualizzazioni di pagina di persone che stanno solo sfogliando i record, cadrà in un'applicazione ad alta intensità di scrittura (e-commerce, messageboard, ecc.).
Jamieb,

10

La scalabilità di SQLite dipenderà fortemente dai dati utilizzati e dal loro formato. Ho avuto una dura esperienza con tavoli extra lunghi (record GPS, un record al secondo). L'esperienza ha dimostrato che SQLite rallenterebbe a tappe, in parte a causa della costante riequilibrio dei crescenti alberi binari che tengono gli indici (e con gli indici cronodatati, è sufficiente sapere che l'albero sta per arrivare riequilibrate un sacco, ma è di vitale importanza per la vostra ricerche). Quindi alla fine a circa 1 GB (molto ballpark, lo so), le domande diventano lente nel mio caso. Il tuo chilometraggio varierà.

Una cosa da ricordare, nonostante tutto il vantarsi, SQLite NON è fatto per il data warehousing. Esistono vari usi non consigliati per SQLite. Le brave persone dietro SQLite lo dicono da sole:

Un altro modo di guardare a SQLite è questo: SQLite non è progettato per sostituire Oracle. È progettato per sostituire fopen ().

E questo porta all'argomento principale (non quantitativo, scusate, ma qualitativo), SQLite non è per tutti gli usi, mentre MySQL può coprire molti usi diversi, anche se non idealmente. Ad esempio, è possibile che MySQL memorizzi i cookie di Firefox (anziché SQLite), ma è necessario che il servizio sia sempre attivo. D'altra parte, potresti avere un sito Web transazionale in esecuzione su SQLite (come fanno molte persone) invece di MySQL, ma aspettati molti tempi di inattività.


1
Puoi ovviare al problema di avere tabelle indicizzate molto grandi condividendo i tuoi dati, ad esempio una tabella al giorno / settimana. SQLite ti consente persino di dividere le tabelle in file di database distinti e quindi di utilizzarle ATTACH DATABASEper creare una connessione al database virtuale con tutte le tabelle (tuttavia è limitata a 62 database).
Alix Axel,

3

penso che un server web (nei numeri 1) che serve centinaia di client appare sul back-end con una singola connessione al database, non è vero?

Quindi non esiste un accesso simultaneo nel database e quindi possiamo dire che il database funziona in "modalità utente singolo". Non ha senso disconoscere l'accesso multiutente in tale circostanza e quindi SQLite funziona così come qualsiasi altro database basato su server.


1
Thx GateKiller, ma specifica "sito Web a basso volume".
Ghiaccio,

3

Pensare in questo modo. SQL Lite verrà bloccato ogni volta che qualcuno lo utilizza (SQLite non si blocca in lettura). Quindi, se offri una pagina web o un'applicazione che ha più utenti simultanei, solo uno potrebbe usare la tua app alla volta con SQLLite. Quindi, c'è un problema di ridimensionamento. Se si tratta di un'applicazione per una sola persona che dice una libreria musicale in cui si possiedono centinaia di titoli, classificazioni, informazioni, utilizzo, riproduzione, tempo di riproduzione, allora SQL Lite scalerà magnificamente tenendo migliaia se non milioni di dischi (disco rigido disponibile)

MySQL, d'altra parte, funziona bene per le app dei server in cui le persone lo useranno contemporaneamente. Non si blocca ed è di dimensioni piuttosto grandi. Quindi per la tua libreria musicale MySql sarebbe finita per uccidere come solo una persona lo vedrebbe, A MENO CHE questa non sia una libreria musicale condivisa in cui migliaia la aggiungono o aggiornano. Quindi MYSQL sarebbe quello da usare.

Quindi in teoria MySQL si ridimensiona meglio di Sqllite perché può gestire utenti multipli, ma è eccessivo per una singola app utente.


5
lo / lo usa / lo scrive. sqlite non si blocca in lettura.
Gregg Lind,

5
bene, la tua risposta può essere male interpretata facilmente. SQLite si blocca solo su richieste di scrittura . Utilizziamo SQLite per oltre 50 GB di dati medici in forma relazionale e serviamo centinaia di client Web simultanei per la navigazione e le query. Le sue prestazioni di lettura non sono mai peggiori di un recente MySQL.
Berk D. Demir

3
MyISAM di MySQL non è molto meglio per l'accesso simultaneo di SQLite. MySQL utilizza molto i blocchi a livello di tabella e non esegue scritture simultanee, tranne in alcuni casi in cui il layout di MyISAM è ottimale. A meno che tu non scelga InnoDB (che ha i suoi problemi come la riduzione del file di dati), potresti non stare molto meglio con MySQL.
Kornel,

1

Il sito Web di SQLite (la parte a cui si fa riferimento) indica che può essere utilizzato per una varietà di situazioni multiutente.

Direi che può gestire un bel po '. Nella mia esperienza è sempre stato molto veloce. Naturalmente, è necessario indicizzare le tabelle e quando si codifica contro di essa, è necessario assicurarsi di utilizzare query con parametri e simili. Fondamentalmente le stesse cose che faresti con qualsiasi database per migliorare le prestazioni.


e utilizzare le transazioni. Questo è fondamentale per SQLite.
Kornel,

-1

Potrebbe valere la pena dare un'occhiata a REAL SQL Server , che è un server di database basato su SQLite.


7
Non credo che nessun sito meriti di spendere $ 299 per "REAL SQL Server" quando la maggior parte dei siti non riceve abbastanza traffico per persino iniziare a raggiungere i limiti di SQLLite.
Djangofan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.