architecture - ¿Qué significa escalabilidad para ti?
scalability (10)
Actualmente, y especialmente para webapps, pero en algunos casos también para aplicaciones empresariales, la escalabilidad horizontal es lo que desea tener,
¿Puedo manejar más (tráfico, datos, procesamiento) agregando más hardware básico? incluso usando "servidores en la nube" amazon ec2, motor de la aplicación google y similares?
Publiqué una pregunta similar sobre qué tan escalable es linq. Había tantos puntos de vista diferentes sobre lo que significaba la escalabilidad en algunas conversaciones recientes, por lo que me ha motivado hacer esta pregunta también. ¿Qué significa escalabilidad para ti?
Escalabilidad significa la capacidad de manejar el crecimiento en cualquiera de estas 2 áreas:
1) Facilidad de agregar nuevas características, corregir errores. Para hacer que el código haga estas cosas nuevas, ¿qué tan difícil es hacerlo? Si bien esto puede ser mantenible de alguna manera, también es la cuestión de si puede construir el código para manejar una escala más grande fácilmente.
2) Capacidad para manejar una carga mayor y mayor que pueden ser múltiples solicitudes simultáneamente en Desarrollo web o conjuntos de datos más grandes para un sitio web simple basado en Bases de datos, por ejemplo, podría hacer una aplicación que maneje tablas con cientos de miles de filas que todavía se ven como " rápido"?
Generalmente, para mí, la escalabilidad significa la capacidad de crecer.
Escalabilidad: la capacidad de un sistema para usar recursos adicionales para lograr una mayor capacidad o rendimiento. Recursos adicionales tales como unidades, memoria, tarjetas de red, procesadores o máquinas.
No asocio directamente la escalabilidad con el crecimiento de características, aunque puede que no sea posible agregar funciones a un sistema en su límite de escala.
Escalable significa que puedo incorporar recursos en un sistema y crecerá en espacio y tiempo entre O (log (n)) y O (n log n). Eso es poco realista, pero así es como pienso en "escalable".
No creo que la escalabilidad tenga un ápice de sentido sin contexto.
Cuando me preguntan sobre la escalabilidad de un sistema, lo primero que necesito saber es cómo se espera que su utilización crezca. ¿Recibirá más usuarios? ¿Los usuarios existentes harán un mayor uso de él? ¿Su conjunto de características crecerá? ¿Cambiará la combinación de transacciones que actualmente está apoyando? ¿La experiencia del usuario deberá cambiar?
(De acuerdo, entonces la respuesta a todas esas preguntas suele ser "Sí", luego anteponga la palabra "Cómo" a esas preguntas).
Para elegir un ejemplo no completamente ficticio: un sistema que actualmente admite muy pocos usuarios, y cuya base de usuarios se espera que crezca rápidamente, tiene un problema de escalamiento grave si el DBA tiene que pasar dos horas realizando consultas manualmente a partir de la información seleccionada de los mensajes de correo electrónico cada tiempo que tiene que configurar una nueva cuenta. No se trata de un problema que pueda solucionarse agregando más recursos, a menos que incluya DBA en la lista de recursos que va a agregar (y hay muchas razones por las que no se ampliará bien).
O imagine un sitio de redes sociales que despliegue la nueva función emocionante que puede ver si sus amigos están en línea y chatee con ellos a través de una agradable interfaz de usuario de Ajax-y. De repente, sin un aumento en la base de usuarios, el número de solicitudes HTTP que manejan sus servidores por día aumenta veinte veces, y sus preocupaciones sobre la escalabilidad de su base de datos retroceden en segundo plano. (A menos que, por supuesto, haya involucrado la base de datos en su aplicación de chat. ¡Buena idea!)
Claro, hacer que sus aplicaciones web sean sin estado para que pueda agregar servidores web, hacer las páginas web idempotentes para que pueda agregar proxies, diseñando su aplicación para que pueda particionar su base de datos en todos los servidores, eso hará que su aplicación sea escalable en varios dimensiones. Vale mucho la pena pensar en eso. Pero es mucho más importante descubrir cuál es tu verdadero enemigo antes de que comiences a pelear.
Respondí esa pregunta como si quisieras decir rápido, pero eso es porque no quería ser un idiota :), lo que significa que no quería iniciar una discusión sobre qué significa escalable. Considero escalable como: agregar recursos al sistema aumenta su rendimiento.
En ese sentido, PLINQ es escalable, porque agregar más núcleos lo hará funcionar más rápido.
Solo para agregar a la publicación de @Lou Franco.
PLINQ incluso tiene un desempeño "Súper lineal" anormal en algunos escenarios con sobrecarga limitada (de acuerdo con algunas de sus demos). Pruébalo.
Si eres un chico de C ++, Microsoft también está buscando lanzar características de simultaneidad que aparentemente no tienen costos de tiempo de ejecución asociados con ellas y herramientas adicionales de concurrencia basadas en tareas para ayudarte a llamar mejor.
Veo la escalabilidad desde dos perspectivas:
Ampliar
Si agrego más RAM a la caja en la que algo se está ejecutando, ¿cuánto rendimiento y capacidad adicionales obtengo? Si una aplicación que tengo puede manejar 300 conexiones más y funciona un 15% más rápido cuando agrego 2 GB de RAM a mi servidor y otra aplicación solo puede manejar 100 conexiones más y funciona un 5% más rápido, la aplicación A es claramente más escalable.
Escalar
Ahora, si agrego más cuadros a mi configuración, ¿cuánto rendimiento y capacidad adicionales obtengo? ¿Puedo configurar interfaces web para manejar más tráfico del cliente? Si es así, ¿hay un aumento lineal? Si agrego 3 cuadros, ¿puedo obtener 3 veces más usuarios accediendo a mi sitio? ¿Puedo agregar más bases de datos para distribuir la carga de datos? ¿Puedo ampliar el multihilo? Si puedo agregar fácilmente una máquina a mi red para agregar capacidad a mi aplicación, entonces es escalable.
Por cierto, esta es una de las unidades principales de n-tier.
Pienso en la escalabilidad como una medida de la suavidad de la curva costo-rendimiento.
Es decir, si puede gastar un poco en recursos informáticos y obtener un sistema de bajo rendimiento, y agregar recursos gradualmente puede obtener un sistema proporcionalmente mejor, es escalable. Si tiene que agregar recursos en trozos caros, para obtener mejoras menos que lineales, no es escalable.
Woh !, gran palabra ...
Lo defino como nuevo en cada proyecto, porque depende de lo que el cliente quiera.
La escalabilidad no siempre se trata de agregar capacidad de procesamiento / almacenamiento, sino que también puede incluir el soporte de muchas entradas y muchas salidas.