Siti Web per uso interno: esiste un caso convincente contro SQLite?

Molti framework Web, come Flask o Django, utilizzano SQLite come database predefinito. SQLite è avvincente perché è incluso in Python e il sovraccarico amministrativo è piuttosto basso.

Tuttavia, la maggior parte dei siti di produzione pubblica ad alto traffico finiscono con un database più pesante: mySQL, Oracle o postgresql.

Le domande :

Assumere:

• Il traffico del sito è moderato e si verificherà l'accesso simultaneo in lettura / scrittura al database
• Useremo SQLAlchemy con i blocchi di scrittura di SQLite (anche se questo commento mi rende un po 'nervoso)
• Il database conterrà forse 60.000 record
• Le strutture di dati non richiedono funzionalità avanzate presenti nei database più pesanti

Esiste mai un caso convincente contro la concorrenza SQLite per i siti Web che fungono da strumenti aziendali interni a traffico moderato? In tal caso, quali condizioni causeranno problemi di concorrenza a SQLite ?

Sto cercando specifiche cause alla radice note, invece di paura generale / puntamento del dito non comprovato.

Consiglio di leggere la risposta ufficiale alla tua domanda, Usi appropriati per SQLite . In particolare, "Situazioni in cui un altro RDBMS può funzionare meglio" avverte che SQLite non supporta la scrittura simultanea:

SQLite supporta un numero illimitato di lettori simultanei, ma consentirà un solo writer in qualsiasi momento nel tempo. Per molte situazioni, questo non è un problema. Ogni applicazione fa in modo che il suo database funzioni rapidamente e vada avanti e nessun blocco dura più di qualche decina di millisecondi. Ma ci sono alcune applicazioni che richiedono più concorrenza e quelle applicazioni potrebbero aver bisogno di cercare una soluzione diversa.

Dal punto di vista dell'adeguatezza, tendo a considerare SQLite come un formato di file molto sofisticato che supporta le query SQL. Tenderei ad evitare SQLite se volessi separare il mio database dalla mia applicazione web, poiché non è ottimizzato per questo caso. In breve, SQLite non è sufficientemente scalabile per l'uso in alcuni scenari, quindi le persone che gestiscono siti Web che sperano un giorno di diventare popolari potrebbero essere meglio iniziare con qualcosa di scalabile, piuttosto che andare con SQLite e in seguito essere costretti a cambiare.

Detto questo, SQLite probabilmente va bene per la maggior parte dei siti Web interni; in genere i siti Web interni non richiedono lo stesso livello di concorrenza e scalabilità.

Indossando il mio cappello da direttore IT vedo alcuni no-go qui:

• Rischio di corruzione dei dati. Forse più percepito che reale, ma alla fine della giornata si tratta di un tipo di file non transazionale DB che non ha molto se qualsiasi ricorso a scritture errate oltre a chiedere se si dispone di un backup recente. A proposito. . .
• Come posso sostenere questa cosa? In un certo senso so di averne una buona copia. Preferibilmente senza portare l'app offline.
• Come posso proteggere l'accesso al DB? La mia comprensione generale è che SQL Lite non ha nulla al di fuori dell'accesso al filesystem, il che è un inizio decente ma non il tutto, fine tutto. Soprattutto per le app Web in cui potresti desiderare più autorizzazioni graduate rispetto a DBA o niente.

Dal punto di vista dello sviluppatore, penso che sia importante sapere perché SqlLite è l'impostazione predefinita, perché è facile e dimostra bene. Se stai "vendendo" una piattaforma a nuovi sviluppatori, è fondamentale poter accendere un'app Web funzionante con il minimo sforzo. E dover alzarsi e configurare correttamente un server di database sarebbe un grosso ostacolo da evitare.