Cosa rende scalabile un'applicazione?

Continuo a vedere nelle offerte di lavoro che il candidato deve avere esperienza nella scrittura di domande "scalabili". Cosa rende scalabile un'applicazione e come faccio a sapere che il mio codice può essere ridimensionato a milioni di utenti?

Immagino che un modo migliore per formulare questa domanda sia: come posso scrivere il mio codice pensando alla scalabilità? In modo che il codice sia scalabile fin dall'inizio piuttosto che un ripensamento. Esistono alcune metodologie di progettazione? Oppure si tratta semplicemente di scegliere gli algoritmi corretti per il lavoro?

Esistono due direzioni di scalabilità:

• verticale (aka scaling up): CPU più veloce, più RAM, più spazio su disco;
• orizzontale (noto anche come ridimensionamento): più core nella CPU, più CPU, più server;

Per il primo, devi solo fare attenzione a non avere limiti arbitrari. Questi a causa di dimensioni intere troppo piccole o strutture a lunghezza fissa / limitata. Queste strutture potrebbero essere correlate al sistema operativo sottostante. Ad esempio, se provi a ridimensionare utilizzando più thread o processi, a un certo punto raggiungerai i limiti del sistema operativo. Ecco perché attualmente i server creati per l'alta scalabilità stanno facendo concorrenza sulla base di eventi asincroni. Questo problema è descritto nel famoso documento C10K .

Il secondo è più difficile. Richiede una programmazione con due cose in mente: i dati verranno elaborati in parallelo e i dati potrebbero essere distribuiti fisicamente. La comunicazione tra i nodi dovrebbe essere limitata. In pratica ciò significa di solito sacrificare alcune parti di ACID (è dimostrato che non è possibile avere ACID completo e capacità di ridimensionamento allo stesso tempo). La soluzione più nota per l'archiviazione dei dati in quel paradigma sono le soluzioni NoSQL . Si va da negozi di valori-chiave molto semplici, a sistemi simili a RDBMS, spogliati solo della possibilità di fare join. I negozi di valore-chiave sono ultra-scalabili, ma questo ha un prezzo. Fondamentalmente puoi eseguire una query solo sulla chiave primaria. C'è comunque una soluzione a ciò, la riduzione della mappa. Potrebbe sembrare molto non ottimale se si guarda al punto di vista della complessità cumulativa, ma bisogna tenere a mente che sta funzionando in modo massiccio parallelo.

Se vuoi saperne di più sulla scalabilità con esempi di vita reale, consulta il blog HighScalability.com .

La scalabilità è misurata in termini di throughput in base ad alcune variabili. Ad esempio, numero di richieste / secondo con utenti X. Il modo più semplice per descrivere la scalabilità è:

Una misura dell'efficienza all'aumentare del carico.

La prima cosa che devi capire nella progettazione per la scalabilità è quale misura è più importante per la tua applicazione? Esistono diversi modi per misurare l' efficienza, che è un componente chiave della scalabilità:

• Richieste simultanee al secondo
• Tempo medio di risposta per richiesta
• Numero di record elaborati al secondo / minuto

Esistono più misurazioni dell'efficienza che è possibile utilizzare, ma sono comuni per i sistemi basati sul Web o per l'elaborazione in batch.

Il prossimo aspetto della scalabilità è misurare ciò che accade alla tua efficienza all'aumentare del carico. I modi più comuni per aumentare il carico sono:

• Più utenti colpiscono il server (cioè più traffico web)
• Più dati nel database (ovvero le query impiegano più tempo o l'elaborazione richiede più tempo)
• Guasto del disco rigido in un RAID (le prestazioni / affidabilità della memoria sono influenzate)
• Saturazione della rete

L'obiettivo di un'applicazione scalabile è mantenere o migliorare l'efficienza mentre affrontiamo il problema del carico. In breve, se il tempo di risposta impiega troppo tempo, possiamo aggiungere un altro server per distribuire uniformemente il carico? Questo approccio riduce la quantità di lavoro per un server e mantiene i server operativi in ​​quel "punto ottimale" per l'efficienza.

La tua applicazione dovrà essere progettata specificamente per il ridimensionamento. Ciò significa che devi stare attento con i dati della sessione, instradare le richieste al server giusto, riducendo i colli di bottiglia che limitano la possibilità di ridimensionamento dell'applicazione.

Fondamentalmente si desidera evitare colli di bottiglia delle prestazioni quando si aumenta il numero di utenti e / o si elabora un set di dati più grande e / o si offre la propria interfaccia in più lingue, ecc.

Praticamente dai un'occhiata allo schema del tuo database, ai tuoi algoritmi e al tuo processo di sviluppo del software e provi a prevedere problemi futuri. Si desidera inoltre impostare il monitoraggio delle prestazioni per identificare i problemi quando iniziano a svilupparsi.

Ho raccolto questi suggerimenti quando ho letto Costruire siti Web scalabili (link ad Amazon).

Spero che sia di aiuto!

L'unico modo in cui le applicazioni possono essere veramente scalabili è non avere restrizioni che non possono essere superate (o solo in modo molto costoso).

Un esempio tipico è cosa succede quando si esauriscono i cicli cpu disponibili? Se il tuo programma è multi-battistrada, puoi eseguire su una scatola con più core, ma cosa succede quando non puoi più acquistare una scatola più grande? La tua applicazione semplicemente non può più crescere e quindi non è scalabile.

Qualsiasi applicazione veramente scalabile deve essere in grado di diffondersi su più computer in modo trasparente e di farlo senza alcun rilievo evidente. Questo non è facile ed è uno dei motivi per cui Google ha avuto tanto successo.

Ci sono problemi unici che derivano dal supporto di applicazioni su larga scala. L'offerta di lavoro è alla ricerca di candidati che abbiano lavorato in quell'ambiente e che abbiano dovuto risolvere tali problemi.

Da un'applicazione di alto livello vengono rese scalabili ponendo costantemente la domanda che cosa accadrebbe se questo pezzo di codice fosse richiesto per essere eseguito migliaia di volte in un periodo molto piccolo. Ciò significa gestire le impronte della memoria, utilizzare la memorizzazione nella cache di totali e dati, utilizzare origini dati scalabili, ecc.

Se stavi costruendo una funzione di ricerca che ha funzionato bene quando ha 100 righe nel DB da cercare e 10 utenti che la utilizzano contemporaneamente. Quanto sarebbe efficace se 100 utenti lo usassero contemporaneamente e ci fossero 100K righe da cercare.

Se funziona allo stesso modo, non importa cosa sia, quindi è molto buono. se funziona in modo proporzionale alla quantità di utenti / dati (ovvero 10 volte più dati == 10 volte più da elaborare) va bene. Se si comporta molto più in basso, maggiore è il numero di dati che ha (dati in modalità 10x == 10x ^ 10 più lunghi da elaborare), quindi non si adatta bene.

I miei esempi dovrebbero davvero essere mostrati nella notazione Big O ma al momento non lo so abbastanza bene per scrivere gli esempi in Big O.

Puoi simulare più dati scaricando dati fittizi nel tuo DB e ci sono strumenti per simulare più utenti come Apache AB.