Motivi per il ridimensionamento di NO vs. -out?

Question

Come programmatore faccio scoperte rivoluzionarie ogni pochi anni. Sono davanti alla curva, o dietro di circa π nella fase. Una lezione difficile che ho imparato è che il ridimensionamento OUT non è sempre migliore, spesso i maggiori guadagni in termini di prestazioni sono quando ci siamo riorganizzati e scalati.

Quali motivi avete per il ridimensionamento verso l'alto? Prezzo, prestazioni, visione, utilizzo previsto? Se è così, come ha funzionato per te?

Una volta ridimensionati a diverse centinaia di nodi che serializzavano e memorizzavano nella cache i dati necessari su ciascun nodo ed eseguivano i processi matematici sui record. Molti, molti miliardi di record dovevano essere (incrociati) analizzati. Era il caso aziendale e tecnico perfetto per impiegare scale-out. Abbiamo continuato a ottimizzare fino allo e abbiamo elaborato circa 24 ore di dati in 26 ore a parete. Per farla breve, abbiamo affittato un gigantesco (per il momento) IBM pSeries, messo Oracle Enterprise su di esso, indicizzato i nostri dati e finito l'elaborazione di le stesse 24 ore di dati in circa 6 ore. Rivoluzione per me.

Così tanti sistemi aziendali sono OLTP e i dati non sono frammentati, ma il desiderio da parte di molti è di cluster o scalabilità. È una reazione alle nuove tecniche o alle prestazioni percepite?

Le applicazioni in generale oggi o le nostre matrici di programmazione si prestano meglio per il ridimensionamento? Dobbiamo/dovremmo tenere sempre in considerazione questa tendenza in futuro?

Answer 1

Non sorprende che tutto dipenda dal tuo problema. Se è possibile suddividerlo facilmente in sottoproblemi che non comunicano molto, il ridimensionamento consente di ottenere rapidi aumenti di velocità. Ad esempio, la ricerca di una parola in pagine web 1B può essere eseguita da una macchina alla ricerca di pagine 1B o da macchine 1M che eseguono 1000 pagine ciascuna senza una significativa perdita di efficienza (quindi con un incremento di 1.000.000 x). Questo è chiamato "imbarazzante parallelo".

Altri algoritmi, tuttavia, richiedono una comunicazione molto più intensa tra le parti secondarie. Il tuo esempio che richiede l'analisi incrociata è l'esempio perfetto di dove la comunicazione può spesso soffocare il guadagno in termini di prestazioni nell'aggiunta di più caselle. In questi casi, vorrai mantenere la comunicazione all'interno di una (più grande) scatola, andando oltre le interconnessioni ad alta velocità, piuttosto che qualcosa di "comune" come (10-) Gig-E.

Naturalmente, questo è un punto di vista abbastanza teorico. Altri fattori, come l'I/O, l'affidabilità, la facilità di programmazione (una grande macchina a memoria condivisa di solito dà molto meno mal di testa di un cluster) possono avere anche una grande influenza.

Infine, a causa dei vantaggi (spesso estremi) del ridimensionamento mediante l'utilizzo di hardware economico, l'approccio cluster/griglia ha recentemente attirato molta più ricerca (algoritmica). Ciò ha permesso di sviluppare nuovi modi di parallelizzazione che riducono al minimo la comunicazione e quindi fanno molto meglio su un cluster, mentre la conoscenza comune era usata per dettare che questi algoritmi potevano funzionare efficacemente su grandi macchine di ferro ...

Answer 2

Perché scaling up

• è limitata in ultima analisi dalle dimensioni della scatola si può effettivamente acquistare
• può diventare estremamente costo-inefficace, per esempio una macchina con 128 core e 128G ram è molto più costosa di 16 con 8 core e 8 GB di RAM ciascuno.
• Alcune cose non si adattano bene, come le operazioni di lettura dell'IO.
• Ridimensionando, se l'architettura è corretta, è anche possibile ottenere un'alta disponibilità. Una macchina ram a 128-core, 128G è molto costosa, ma per avere una seconda unità ridondante è estorsione.

E anche in una certa misura, perché è quello che fa Google.

Answer 3

Il ridimensionamento è la soluzione migliore per i problemi embarrassingly parallel. Ci vuole un po 'di lavoro, ma una serie di servizi web si adattano a quella categoria (quindi l'attuale popolarità). Altrimenti corri su Amdahl's law, il che significa che per aumentare la velocità devi aumentare la scala. Sospetto che ti sia imbattuto in quel problema. Anche le operazioni con vincoli di IO tendono a fare bene con il ridimensionamento in gran parte perché attendere IO aumenta il% che è parallelizzabile.

Answer 4

Il post del blog Scaling Up vs. Scaling Out: Hidden Costs di Jeff Atwood ha alcuni punti interessanti da considerare, come licenze software e costi di alimentazione.