Persistenza dei dati, schemi e approcci

La mia filosofia generale è sempre stata che i livelli di accesso ai dati dovrebbero essere progettati per essere disconnessi e senza stato. In altre parole, hai un livello database responsabile del recupero di diversi tipi di dati e il suo ritorno e disconnetti immediatamente la connessione (rimettila sul pool)

Se hai cose come il paging, dovrebbe essere implementato a livello di database con la sp delle nr voci per pagina e pagina da recuperare in modo da non dover mantenere nulla di persistente in memoria tra le richieste.

Molti database là fuori hanno un limite rigido al numero di connessioni: ciò significa che, se si assegna il numero x di connessioni per richiesta, si raggiungerà un limite molto presto. Si dovrebbe guardare il pool di connessioni / cache degli oggetti db localmente o nei server cache ecc. Anche la connessione db Init / destroy è un'operazione costosa. Mantieni il pooling e consenti a un proxy di gestirlo in background.

Questo potrebbe non essere un'opinione popolare, ma non sono un grande fan della connessione ai database direttamente dai server web. Un modo per risolvere questo problema è aggiungere livelli di servizio aggiuntivi tra cui è possibile assicurarsi che il db sia astratto. In questo modo, non devi preoccuparti di ridimensionare in modo indipendente / cambiare db / partizionamento / aggiungere livelli di cache in un secondo momento.

Uso un pool di connessioni. Ogni volta che ho finito con uno, lo lancio in pila. Se ne ho bisogno uno, comincio a fare il pieno dello stack fino a quando non trovo una connessione attiva (connessione che non ha scaduto il tempo mentre era in coda). Io uso questo approccio perché ho molte richieste / secondo e le mie connessioni vengono riciclate molto velocemente. Raramente hanno abbastanza tempo per timeout all'interno dello stack. Ovviamente dovrai sincronizzare lo Stack. Uso Redis come database, ma presumo che funzioni per qualsiasi tipo di connessione che abbia un socket sottostante.