Razones para NO aumentar el tamaño frente a -out?

Question

Como programador, realizo hallazgos revolucionarios cada pocos años. Estoy adelantado a la curva, o detrás de ella por aproximadamente π en la fase. Una lección difícil que aprendí fue que escalar no siempre es mejor, con bastante frecuencia los mayores aumentos de rendimiento se producen cuando nos reagrupamos y ampliamos.

¿Qué razones tiene para ampliar o aumentar? Precio, rendimiento, visión, uso proyectado? Si es así, ¿cómo funcionó esto para usted?

Una vez escalamos varios cientos de nodos que serializarían y almacenarían en caché los datos necesarios para cada nodo y ejecutarían procesos matemáticos en los registros. Muchos, muchos miles de millones de registros deben ser (cruzados) analizados. Fue el negocio perfecto y el caso técnico para emplear escalamiento horizontal. Seguimos optimizando hasta procesamos aproximadamente 24 horas de datos en 26 horas reloj de pared. En pocas palabras, alquilamos una gigantesca (por el momento) IBM pSeries, pusimos Oracle Enterprise en ella, indexamos nuestros datos y terminamos procesando las mismas 24 horas de datos en aproximadamente 6 horas. Revolución para mí

Muchos sistemas empresariales son OLTP y los datos no son fragmentados, pero el deseo de muchos es agrupar o ampliar horizontalmente. ¿Es esta una reacción a las nuevas técnicas o al rendimiento percibido?

¿Actualmente las aplicaciones en general o nuestros matras de programación se prestan mejor para escalar? ¿Debemos/debemos tomar esta tendencia siempre en cuenta en el futuro?

Answer 1

No es sorprendente que todo dependa de su problema. Si puede dividirlo fácilmente en subproblemas que no se comunican mucho, la ampliación le brinda aceleraciones triviales. Por ejemplo, la búsqueda de una palabra en páginas web 1B puede realizarse en una máquina que busque 1B páginas, o en máquinas de 1M que tengan 1000 páginas cada una sin una pérdida significativa de eficiencia (por lo tanto, con una aceleración de 1,000,000x). Esto se llama "embarazosamente paralelo".

Otros algoritmos, sin embargo, requieren una comunicación mucho más intensa entre las subpartes. Su ejemplo que requiere un análisis cruzado es el ejemplo perfecto de que la comunicación a menudo puede ahogar los aumentos de rendimiento al agregar más cuadros. En estos casos, querrá mantener la comunicación dentro de un cuadro (más grande), pasando por las interconexiones de alta velocidad, en lugar de algo tan "común" como (10-) Gig-E.

Por supuesto, este es un punto de vista bastante teórico. Otros factores, como la E/S, la confiabilidad y la facilidad de programación (una gran máquina de memoria compartida generalmente da menos dolores de cabeza que un clúster) también puede tener una gran influencia.

Finalmente, debido a los beneficios de costo (a menudo extremos) de ampliar el uso de hardware básico barato, el enfoque de clúster/red ha atraído recientemente mucha más investigación (algorítmica). Esto hace que se hayan desarrollado nuevas formas de paralelización que minimicen la comunicación y, por lo tanto, rindan mucho mejor en un clúster, mientras que el conocimiento común solía dictar que estos tipos de algoritmos solo podían funcionar eficazmente en grandes máquinas de hierro ...

Answer 2

Debido a la ampliación de

• está limitada en última instancia por el tamaño de la caja en realidad se puede comprar
• puede llegar a ser muy poco rentable, por ejemplo, una máquina con 128 núcleos y 128G ram es mucho más costosa que 16 con 8 núcleos y 8G ram cada uno.
• Algunas cosas no se adaptan bien, como las operaciones de lectura IO.
• Al ampliar, si su arquitectura es correcta, también puede lograr alta disponibilidad. Una máquina de ram de 128 núcleos y 128G es muy costosa, pero tener una segunda redundante es exorbitante.

Y también en cierta medida, porque eso es lo que hace Google.

Answer 3

Escalar es mejor para embarrassingly parallel problemas. Se necesita algo de trabajo, pero una serie de servicios web se ajustan a esa categoría (por lo tanto, la popularidad actual). De lo contrario, se encontrará con Amdahl's law, lo que significa que para ganar velocidad no tiene que escalar. Sospecho que te encontraste con ese problema. También las operaciones de IO bound también tienden a funcionar bien con la ampliación en gran medida porque la espera de IO aumenta el% que es paralelizable.

Answer 4

La publicación de blog Scaling Up vs. Scaling Out: Hidden Costs de Jeff Atwood tiene algunos puntos interesantes a considerar, como licencias de software y costos de energía.