Come si fa a caricare il lavoro dal database?

Ecco un elenco di opzioni standard.

1. Ottimizza l'accesso al database per fare solo ciò di cui hai bisogno, in modo efficiente. Un buon DBA può aiutare molto qui. Questo è un passo fondamentale che fa la maggior parte delle aziende.

2. Archivia i dati dal database usando qualcosa come memcached. Questo di solito è fatto a livello di applicazione ed è molto efficace. Praticamente ogni sito web competente dovrebbe farlo.

3. Più ambiziosamente, mantieni le copie di sola lettura del database e indirizza le query lì quando è possibile. Sul lato del database la tecnologia necessaria è chiamata "replica" e le copie di sola lettura sono spesso anche backup per il failover dal database principale. Se stai facendo un milione di pagine dinamiche all'ora, le probabilità sono che tu stia facendo questo o ci hai pensato.

4. Acquista hardware veramente costoso per il database. So che PayPal l'ha fatto come 4 anni fa e cambiare la loro architettura sarebbe stato difficile, quindi probabilmente lo sono ancora.

5. Shard il database in più parti con intervalli di dati. Questo è un cambiamento molto intrusivo nel design dell'applicazione. Un noto esempio di società che fa questo è eBay.

6. Prova ad usare un database che si adatta a più macchine. Oracle RAC scala su cluster, ma non ti consente di distribuire i dati ampiamente. Esistono altre offerte che dovrebbero essere più facili da distribuire, incluso Microsoft SQL Azure e FathomDB . Non ho usato quelle offerte e non so quanto bene funzionano. Sospetto meglio di niente, ma dubito che scalino orizzontalmente così bene.

7. I database relazionali in genere cercano di fornire garanzie ACID . Ma il CAP teorema rende molto difficile farlo in un sistema distribuito, in particolare mentre ti permette di fare cose come unire i dati. Pertanto le persone hanno escogitato molte alternative NoSQL che offrono esplicitamente garanzie più deboli ed evitano operazioni problematiche in cambio di una scalabilità completamente distribuita. Esempi ben noti di aziende che utilizzano archivi di dati NoSQL scalabili includono Google, Facebook e Twitter.

Il 90% del problema sta ottimizzando le query del database e configurando correttamente il server. Assicurati di avere indici appropriati, che le query non stiano eseguendo scansioni di riga, ecc. Usa qualsiasi strumento di profilatura offerto dal tuo database. Sareste sorpresi di quanto questo possa influenzare un server. Molte aziende si affretteranno e compreranno un nuovo server di database quando tutto ciò di cui hanno veramente bisogno sono un paio di indici extra per ridurre il carico.

Una volta che le query sono state ottimizzate il più possibile e il server DB è ancora sovraccarico, utilizzare replica del database per distribuire il carico di lavoro. Invece di un singolo server di database sovraccarico, dividerlo in 2 o più, con gli altri che replicano il master. Quindi fai in modo che le pesanti query di sola lettura (report, ecc.) Funzionino contro i database replicati e colpiscano solo il database master per query semplici e inserti / aggiornamenti.

How do you reduce the database's workload?

• Memorizza i dati sui server Web in modo che il livello aziendale non effettui chiamate ridondanti al database. [I framework ORM come Hibernate possono aiutare con questo.]

Easy, until you realize that now you've got a ton of traffic internally as a web server tries to run SELECT TOP 3000 (presumably to crunch the results on its own), which still slows things down.

• Pianifica i lavori che anticipano la necessità di eseguire pesanti calcoli e aggregazioni e memorizza i risultati nella cache dell'applicazione (accessibile a tutte le richieste).

One way I've heard from some answers here to take load off the database is to offload the work to the web server. Easy, until you realize that now you've got a ton of traffic internally as a web server tries to run SELECT TOP 3000 (presumably to crunch the results on its own), which still slows things down.

Penso che potresti prenderlo un po 'troppo alla lettera. Non si tratta di fare in modo che i server Web eseguano lo stesso calcolo del database. Nella maggior parte delle applicazioni esistono opportunità di memorizzare nella cache non solo il set di risultati del database, ma in realtà di memorizzare nella cache il risultato finale di qualunque sia il set di risultati utilizzato (in genere per generare del contenuto su una pagina).

Ad esempio, supponiamo di avere un elenco di post più popolari su un blog che è relativamente costoso da interrogare dal database. Senza il caching, se il tuo blog subisce improvvisamente un aumento di traffico intenso, l'applicazione del tuo blog interroga ripetutamente il database per generare l'elenco "post più popolari" per ogni caricamento di pagina e rapidamente fallire sotto carico. Supponiamo ora di memorizzare nella cache l'elenco di post popolari in memoria per 15 minuti. In questo modo, anche se ottieni un milione di visite in un'ora, il database eseguirà quella query solo quattro volte.

In questo modo stai facendo un compromesso per il più famoso elenco di post sul blog fino a 15 minuti, ma ottenendo un carico significativamente ridotto sul database (e una maggiore scalabilità).

Dichiarazione di non responsabilità: non sono un esperto di server Web, query DB ecc. (non è il mio campo) :)

Detto questo, ho adorato il concetto dimostrato in questa presentazione su Node.js.

( articolo correlato )