Per quale tipo di siti web va bene o meglio usare SQLite? [chiuso]

Sqlite è un database in-process, il che significa che le sue caratteristiche relative alle prestazioni saranno simili a quelle di un'applicazione ottimizzata che utilizza un file per archiviare i dati.

In un cluster IaaS o PaaS, un sito Web Sqlite può essere scalato infinitamente in modo estremamente semplice per siti di piccole dimensioni e di sola lettura. È sufficiente distribuire un nuovo server applicazioni con una copia del file sqlite e, quando il carico di lavoro si dissipa, è sufficiente disporre del server. L'aggiornamento di tale sito può essere fatto applicando un semplice aggiornamento progressivo al cluster di server. In questo tipo di scenario, e specialmente quando i siti gestiscono molte query complesse di sola lettura, sqlite può essere molto più veloce e semplice da scalare rispetto al database tradizionale in quanto non vi è alcuna comunicazione di serializzazione / inter processo coinvolta in ciascuna query.

Questo rende anche sqlite molto adatto come database secondario per un server di applicazioni stateless per archiviare la configurazione prevalentemente statica, i dati storici e le pagine che vengono cambiate raramente per un capriccio.

Sqlite può gestire più autori molto bene , molto meglio della maggior parte degli altri database di processo, ma come limite fondamentale per il database di processo, tutti gli autori devono trovarsi in una singola macchina. Ciò limita la tua applicazione a scrivere carichi di lavoro che possono essere gestiti comodamente su una singola macchina. Se la tua applicazione ha un discreto numero di scrittori, sqlite di solito li gestisce bene. Mentre è possibile distribuire un sito sqlite con il file statico in un file system in rete, il filesystem in rete spesso non ha la corretta implementazione di funzionalità di filesystem più avanzate come flock, flush o memoria condivisa che sono necessarie per assicurare correttezza e correttezza delle transazioni le prestazioni, che rendono la distribuzione di un sito sqlite con scrittori multi-macchina su un filesystem in rete un'attività piuttosto complicata.

La maggior parte dei siti web di piccole e medie imprese che agisce semplicemente come una presenza / biglietto da visita online, contenente poco più di alcune informazioni sulle persone, il prodotto e le informazioni di contatto dell'azienda e probabilmente un piccolo modulo di contatto sono molto adatti al sito sqlite. Questi siti in genere hanno una frequenza di aggiornamenti molto bassa e un singolo server può gestire comodamente pagine di 10k al giorno, il che è molto più che sufficiente per questo tipo di siti, quindi la semplicità di manutenzione è una considerazione molto importante. Sqlite può servire molto bene a questi scenari, dato che puoi aggiornare il sito semplicemente copiando il file sqlite dallo sviluppo e fai il backup del sito scpando il file sqlite in qualche altro posto.

SQLite è un database in-process. Se hai solo un processo in esecuzione sul tuo sito web, allora va bene. Se è necessario avere più di un processo (e probabilmente anche più di un thread) per scrivere nello stesso database, SQLite non fa per te. È così semplice.

Ciò significa che puoi gestire una sola richiesta alla volta [1], che probabilmente è solo di decine di umani sul tuo sito prima che inizino a pensare che sia lento.

1. A meno che l'operazione non sia una lettura pura, ovvero nessuna traccia di sessione, nessuna analisi, nessuna registrazione, nessuna delle molte cose simili che i siti Web moderni vogliono fare

I think that SQLite will suit me better on some of my small websites. My questions are:

Buona idea.

1) Is it worth it to use on relatively small websites?

Sì, vedi sotto perché ....

2) On such websites, does it consume less resources of a server?

Ovviamente, poiché non è necessario alcun server PostGreSQL (un processo in esecuzione sulla stessa macchina o un processo in esecuzione su una macchina diversa ).

3) When in general is it recommended or ok to use SQLite in regards to websites or web services?

Innanzitutto, se pensi che il tuo sito web possa in seguito avere un pubblico abbastanza grande da richiedere risorse di elaborazione più grandi (in particolare, eseguire un RDBMS su qualche macchina altro , o bilanciare il carico su più computer) , potresti voler iniziare con PostGreSQL.

Ma potresti progettare la tua applicazione web per essere più o meno facilmente portabile da SQLite a PostGreSQL. Con cura, dovrebbe essere abbastanza facile; e potresti voler pensare a una tale migrazione (e documentarne qualcosa), anche se accadrebbe tra qualche anno.

Si noti che probabilmente sarà necessario scaricare il database in formato SQL (almeno per scopi di backup). Se il database è abbastanza grande (anche sul sito web che ha pochi hit al giorno) -e.g. molti gigabyte - potrebbe essere una preoccupazione (perché potrebbe essere poco pratico - forse troppo lento - scaricare un database SQLite mentre la tua applicazione web lo aggiorna di frequente). Ma probabilmente non lo è.

Quindi è necessario considerare diversi fattori: come sarà aggiornata l'applicazione web? quanto piccolo è il sito web (in termini di traffico, in termini di velocità di aggiornamento dei dati, in termini di volume di dati)? In che modo è importante essere in grado di migrare (più o meno facilmente) in un secondo momento su un server RDBMS?

Vedi anche questa risposta a una domanda abbastanza correlata sulle dimensioni del database SQLite.