So che i grandi siti Web soffrono di problemi di scalabilità e immagino che più server (hardware) possano aiutare a gestire i problemi di scalabilità, ma vedo che i grandi siti Web sono bloccati sulla scalabilità anche se possono gestire il costo dei nuovi server.
Quindi perché le grandi aziende non gestiscono i problemi di scalabilità da parte di più server?
Introducendo più server, stai introducendo più linee di comunicazione e la necessità di mantenere le cose sincronizzate. Questo non è banale.
La quantità di overhead delle comunicazioni aumenta in modo quadratico con il numero di nodi che comunicano. Se si tenta di centralizzare le comunicazioni, si introduce un collo di bottiglia di scalabilità con le comunicazioni.
Esistono diverse architetture conosciute utilizzate per il ridimensionamento e nessuna di esse è semplice come "aggiungi più server".
Il blog ad alta scalabilità ha pubblicato un post del blog recente giusta questo argomento .
L'aggiunta di altri server delle applicazioni funziona per un po ', ma l'effetto dell'aggiunta di altri server delle applicazioni è che si aumenta il conflitto sul server del database.
I server di database sono molto più difficili da scalare lanciando più computer al problema. Le proprietà ACID che sono alla base del modo in cui vengono utilizzati i database non variano su molti server. Pensa all'applicazione simultanea dei risultati di una transazione su 10 server, quindi cosa succede quando ci sono 100.000 transazioni simultanee in corso.
È qui che entrano i database distribuiti. Questi prodotti non fanno ACID , fanno CAP. Effettivamente devi scegliere due caratteristiche tra coerenza, disponibilità e tolleranza delle partizioni e consentire al terzo di scivolare.
Il modello di programmazione è in genere consistenza finale, quindi le modifiche vengono distribuite nel tempo tra i server del database. (solitamente in ms scale temporali), tuttavia questo non è appropriato ovunque (ad esempio settore bancario con transazioni finanziarie).
Alcuni sistemi affermano di offrire tutte e tre le proprietà CAP, ma devo ancora vederne uno che raggiunge veramente questo
Il database distribuito non esegue SQL, quindi il livello di accesso ai dati è stato riscritto. Questo tipo di cambiamento richiede tempo per essere implementato e richiede nuovi modi di pensare.
"Più server" va bene - e questo è ciò che molte aziende effettivamente fanno. Tuttavia, a meno che il tuo software non sia progettato in modo tale da ridurlo, riscontri molto rapidamente.
La maggior parte delle architetture ha almeno un collo di bottiglia che non è in grado di scalare aggiungendo più server - se si tratta di un database, un servizio di autenticazione, rete, registrazione ... "Getta più hardware" funziona fino a quando non si sposta il collo di bottiglia a quel luogo in cui non funziona più.
Prosciughi più velocemente uno stagno usando più pompe o più secchi, ma ad un certo punto avrai così tanti lavoratori che non potranno tutti accedere alla piscina nello stesso momento e la tua compagnia elettrica non sarà in grado di fornire abbastanza succo per tutte le tue pompe.
La scalabilità è meglio spiegata come:
The ability to increase performance by adding hardware
Quindi aggiungere hardware non "aumenta la scalabilità".
Molti problemi sono in modo imbarazzante parallelo, (come ray tracing), in cui molte attività possono essere intraprese allo stesso tempo senza richiedere la sincronizzazione o la comunicazione tra i lavoratori, ma questa non è la norma.
I siti web di grandi dimensioni tendono ad avere contenuti che cambiano continuamente ed è questa proprietà che rende i sistemi difficili da scalare. Ovunque ci sia comunicazione o sincronizzazione, c'è il potenziale per un collo di bottiglia.
Lo stato di un sito Web è in genere memorizzato in un database e quindi è qui che risiede il collo di bottiglia principale di molti siti Web. Un database deve rimanere coerente e disponibile per essere utile e questo è molto difficile da garantire (i volumi potrebbero essere scritti su questo argomento).
Si riduce a, l'aggiunta di hardware a un problema può aumentare la capacità di calcolare le cose, ma pianificare il flusso di dati in modo che l'aggiunta di hardware acceleri effettivamente il lavoro che si sta eseguendo, mentre allo stesso tempo ha un piano di emergenza per guasto hardware, è estremamente difficile.
Leggi altre domande sui tag performance scalability server