Che cosa rende scalabile un'applicazione?

Ci sono due direzioni di scalabilità:

• verticale (a.k.a. scalare): CPU più veloce, più RAM, più spazio su disco;
• horizontal (a.k.a scaling out): più core nella CPU, più CPU, più server;

Per il primo, devi solo fare attenzione a non avere limitazioni arbitrarie. Questi a causa di dimensioni troppo piccole o strutture di lunghezza fissa / limitata. Queste strutture potrebbero essere correlate al sistema operativo sottostante. Ad esempio, se si tenta di scalare utilizzando più thread o processi, ad un certo punto si raggiungeranno 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 la programmazione tenendo conto di due cose: i dati verranno elaborati in parallelo e i dati potrebbero essere distribuiti fisicamente. La comunicazione tra i nodi dovrebbe essere limitata. In pratica, questo di solito significa sacrificare alcune parti di ACID (è dimostrato che non si può avere ACID completo e capacità di ridimensionare allo stesso tempo). La soluzione più conosciuta per l'archiviazione dei dati in quel paradigma sono le soluzioni NoSQL . Si va da negozi con valori-chiave molto semplici, a sistemi simili a RDBMS, spogliati solo della capacità di fare join. I negozi di valore-chiave sono ultra-scalabili, ma questo è un prezzo. Puoi fondamentalmente interrogare solo sulla chiave primaria. C'è comunque una soluzione a questo, è ridurre la mappa . Potrebbe sembrare molto sub-ottimale se guardi al punto di vista della complessità cumulativa, ma devi tenere a mente che funziona in modo massivo parallelo.

Se vuoi saperne di più sulla scalabilità con esempi di vita reale, dai un'occhiata al HighScalability.com blog .

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

A measure of efficiency as load increases.

La prima cosa che devi capire nella progettazione per la scalabilità è quale misura è più importante per la tua applicazione? Esistono diversi modi per misurare 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 possono essere utilizzate, ma queste sono comuni per i sistemi basati sul Web o per i sistemi di elaborazione in batch.

Il prossimo aspetto della scalabilità sta misurando ciò che accade alla tua efficienza man mano che il carico aumenta. I modi più comuni per aumentare il carico sono:

• Più utenti che colpiscono il server (ovvero più traffico web)
• Altri dati nel database (ad esempio, le interrogazioni richiedono più tempo o l'elaborazione richiede più tempo)
• Errore del disco rigido in un RAID (le prestazioni e l'affidabilità dello storage sono influenzate)
• Saturazione di rete

L'obiettivo di un'applicazione scalabile è quello di mantenere o migliorare l'efficienza man mano che affrontiamo il problema del carico. In breve, se il tempo di risposta sta richiedendo troppo tempo, possiamo aggiungere un altro server per distribuire il carico in modo uniforme? Questo approccio riduce la quantità di lavoro per un server da fare e mantiene i server operativi in quel "punto debole" per l'efficienza.

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

Fondamentalmente vuoi evitare colli di bottiglia nelle prestazioni quando aumenti il numero di utenti e / o elaborare un set di dati più ampio e / o offri la tua interfaccia in più lingue, ecc.

In pratica, dai un'occhiata allo schema del tuo database, ai tuoi algoritmi e al tuo processo di sviluppo del software e cerca di prevedere i problemi futuri. Vuoi anche impostare il monitoraggio delle prestazioni per identificare i problemi quando iniziano a crescere.

Ho raccolto questi suggerimenti quando ho letto Creazione di siti Web scalabili (collegamento a Amazon).

Spero che questo aiuti!

L'unico modo in cui le applicazioni possono essere veramente scalabili, consiste nel non avere restrizioni che non possono essere superate (o solo molto dispendiose).

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

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

Ci sono problemi unici che vengono con il supporto di applicazioni su larga scala. L'annuncio di lavoro è alla ricerca di candidati che hanno lavorato in quell'ambiente e ha dovuto risolvere tali problemi.

Da un'applicazione di alto livello sono resi scalabili ponendo continuamente la domanda che cosa succederebbe se si richiedesse di eseguire migliaia di volte questo pezzo di codice in un periodo molto breve. Ciò significa gestire i tuoi impronte di memoria, facendo uso della memorizzazione nella cache di totali e dati, utilizzando fonti di dati scalabili, ecc.

Se stavi creando una funzione di ricerca che ha funzionato bene quando ha 100 righe nel DB da cercare e 10 utenti lo usano alla volta. Quanto bene si comporterebbe quando 100 utenti lo stavano utilizzando contemporaneamente e ci sono 100K righe da cercare.

Se si comporta allo stesso modo, indipendentemente da ciò che è molto buono. se è proporzionale alla quantità di utenti / dati (il che significa 10 volte più dati == 10 volte più lunghi da elaborare) questo è positivo. Se il rendimento è molto più basso, maggiore è il numero di dati (10x dati di modalità == 10x ^ 10 più lunghi da elaborare), quindi non si adatta bene.

I miei esempi dovrebbero essere mostrati nella notazione Big O, ma al momento non lo conosco abbastanza bene da 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.