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?
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:
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
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.
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:
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.
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.
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.
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à.
ATTACH DATABASEper creare una connessione al database virtuale con tutte le tabelle (tuttavia è limitata a 62 database).
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.
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.
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.
Potrebbe valere la pena dare un'occhiata a REAL SQL Server , che è un server di database basato su SQLite.