Quanto è scalabile SQLite?

Recentemente 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 massimi?

Ieri ho pubblicato un piccolo sito * per tenere traccia del rappresentante che utilizzava 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 era bloccato ogni volta che qualcuno visualizzava la pagina perché conteneva aggiornamenti / inserti. Presto sono passato a MySQL e mentre non ho avuto molto tempo per testarlo, sembra molto più scalabile di SQLite. Ricordo solo i carichi di pagina lenti e occasionalmente ricevo un errore di blocco del database durante il tentativo di eseguire query dalla shell in sqlite. Detto questo, sto gestendo 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 concorrenti. Morale della trama: usa solo SQLite per i siti web in cui gli aggiornamenti del database si verificano raramente (meno spesso di ogni pagina caricata).

modifica : ho appena realizzato che potrei non essere stato corretto con SQLite: non ho indicizzato alcuna colonna nel database SQLite quando lo stavo servendo da una pagina web. Ciò ha parzialmente causato il rallentamento che stavo vivendo. Tuttavia, l’osservazione delle basi di blocco del database – se si dispone di aggiornamenti particolarmente onerosi, le prestazioni di SQLite non corrisponderanno a MySQL o Postgres.

un’altra modifica: Da quando ho postato questo quasi 3 mesi fa ho avuto l’opportunità di esaminare da vicino la scalabilità di SQLite, e con alcuni trucchi può essere abbastanza scalabile. Come accennato nella mia prima modifica, gli indici di database riducono drasticamente il tempo di interrogazione, ma questa è più un’osservazione generale sui database che non su SQLite. Tuttavia, c’è un altro trucco che puoi usare per velocizzare SQLite: le transazioni . Ogni volta che si devono eseguire più scritture di database, inserirle in una transazione. Invece di scrivere (e bloccare) il file ogni volta che viene emessa una query di scrittura, la scrittura avverrà una sola volta al termine della transazione.

Il sito che menziono che ho pubblicato nel primo paragrafo è stato ritriggersto su SQLite, e funziona senza problemi una volta che ho sintonizzato il mio codice in alcuni punti.

* il sito non è più disponibile

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

Ma è single-user, quindi dipende da che tipo di ridimensionamento stai parlando.

In risposta ai commenti. Si noti che non c’è nulla che impedisca l’uso di un database Sqlite in un ambiente multiutente, ma ogni transazione (in effetti, ogni istruzione SQL che modifica il database) prende un blocco sul file , che impedirà ad altri utenti di accedere al database a tutto

Quindi, se si apportano molte modifiche al database, in pratica si verificheranno problemi di ridimensionamento molto rapidi. Se, d’altra parte, si dispone di un sacco di accesso in lettura rispetto all’accesso in scrittura, potrebbe non essere così male.

Ma Sqlite funzionerà ovviamente in un ambiente multiutente, ma non funzionerà bene.

SQLite guida il sito web sqlite.org e altri che hanno molto traffico. Suggeriscono che se si hanno meno di 100k di colpi al giorno, SQLite dovrebbe funzionare correttamente. E questo è stato scritto prima di consegnare la funzionalità “Writeahead Logging”.

Se vuoi velocizzare le cose con SQLite, fai quanto segue:

  • aggiornamento a SQLite 3.7.x
  • Abilita la registrazione write-ahead
  • Esegui il seguente pragma: “PRAGMA cache_size = Number-of-pages;” La dimensione predefinita (Numero di pagine) è di 2000 pagine, ma se si aumenta quel numero, si aumenterà la quantità di dati che viene eseguita direttamente dalla memoria.

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

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

Solitamente SQLite funziona in modo ottimale come motore di database per siti Web con traffico medio-basso (vale a dire il 99,9% di tutti i siti Web). La quantità di traffico Web che SQLite può gestire dipende, ovviamente, da quanto pesantemente il sito Web utilizza il suo database. In generale, qualsiasi sito che riceve meno di 100.000 accessi al giorno dovrebbe funzionare correttamente con SQLite. La cifra di 100.000 colpi / giorno è una stima prudente, non un limite superiore difficile. È stato dimostrato che SQLite funziona con una quantità di traffico 10 volte maggiore.

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 scelta valida per qualsiasi applicazione che deve supportare l’accesso simultaneo in scrittura all’archivio dati. Ciò include a un certo livello la maggior parte dei siti web mai creati. Se devi anche accedere per qualcosa, probabilmente hai bisogno di accedere in scrittura al DB.

La scalabilità di SQLite dipenderà molto dai dati utilizzati e dal loro formato. Ho avuto alcune esperienze difficili con tavoli extra lunghi (record GPS, un record al secondo). L’esperienza ha dimostrato che SQLite rallenterebbe gradualmente, in parte a causa del costante riequilibrio degli alberi binari in crescita che tengono gli indici (e con gli indici timbrati, sapete solo che l’albero sta per essere ribilanciato molto, ma è vitale per il vostro ricerche). Quindi alla fine a circa 1 GB (molto ambito, lo so), le query diventano lente nel mio caso. Il tuo chilometraggio varierà.

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

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

E questo porta all’argomento principale (non quantitativo, scusato, ma qualitativo), SQLite non è per tutti gli usi, mentre MySQL può coprire molti usi diversi, anche se non idealmente. Ad esempio, potresti avere MySQL per memorizzare i cookie di Firefox (anziché SQLite), ma è necessario che il servizio funzioni sempre. D’altra parte, potresti avere un sito web transazionale in esecuzione su SQLite (come fanno molte persone) invece di MySQL, ma si aspettano un sacco di tempi di inattività.

Penso che un (in numero 1) server web che serve hundert di client appare sul back-end con una singola connessione al database, non è vero?

Quindi non esiste un accesso concorrente nel database e quindi possiamo dire che il database funziona in “modalità utente singolo”. Non ha senso passare inosservato l’accesso multiutente in tale circostanza e così SQLite funziona come qualsiasi altro database basato sul server.

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

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

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

Potrebbe valere la pena di verificare REAL SQL Server , che è un server di database costruito su SQLite.

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. Ovviamente, è necessario indicizzare le tabelle e quando si esegue la codifica, è necessario assicurarsi di utilizzare query parametrizzate e simili. Fondamentalmente le stesse cose che dovresti fare con qualsiasi database per migliorare le prestazioni.