-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 7, 2009, at 1:13 PM, Antonio Ognio wrote: > El día 7 de mayo de 2009 12:53, Felix Manuel Arismendi Quispichuco > <[email protected]> escribió: >> Mira lo único que te puedo decir, es que les por completo el enlace >> que >> pasé y que vuelvo a colocar: >> >> http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tn012.pdf >> > > De acuerdo. Seguiré tu sugerencia. >
A ver, ordenémonos: Lo que critiqué de los correos iniciales de Felix fue que mencionaba entre otras cosas que: 1- .NET no escala como otras tecnologías libres 2- hay benchmarks en los que java escala mejor que php (performance) 3- la tecnología usada es inherente a la escalabilidad 4- la escalabilidad es un punto débil de ruby Luego pone un pdf ACADÉMICO (bastante interesante) en el que se menciona que hay 2 conceptos comunes de escalabilidad: 1- un concepto limitado usado informalmente, en el que un sistema escala bien sin necesidad de agregar mas recursos (hardware, nodos o lo que sea) 2- un concepto en el que la escalabilidad se logra agregando recursos al sistema de una manera razonablemente económica. Si se analiza en serio el asunto, es fácil darse cuenta que el concepto 1 (el que defiende Felix) NO ES ESCALABLE. Simplemente porque va a llegar un momento en el que el crecimiento va a llegar al límite de los recursos del sistema (hardware, red, etc). Si este crecimiento no se da, perfecto, pero eso NO HACE escalable el sistema. Cuál es la solución a una arquitectura pensada con el primer concepto de escalabilidad cuando se llega al límite del sistema? Escalar verticalmente, es decir, hacer un "upgrade" o un "reemplazo" al sistema (que de por si ya rompe con el concepto 1). Esto a la larga tampoco escala, por un factor económico (por ejemplo, un procesador el doble de rápido no tiene el doble del precio, normalmente es 4 o mas veces mas caro). Cómo se escala a gran escala En La Cancha (no en la Academia)? Con el concepto 2. Escalando horizontalmente. Diseñando una ARQUITECTURA que permita un crecimiento agregando nodos. Esto hace que el diseño de la ARQUITECTURA sea distinto a lo clásico: manejar sesiones de una manera distinta, denormalizar data, no usar joins, hacer sharding, federation, etc. Todas estas cosas son TOTALMENTE INDEPENDIENTES del lenguaje usado. Se puede hacer tanto con java como con php. Es por esto que escalabilidad y performance NO SON SINÓNIMOS. Ambas son metas importantes, pero en muchos casos, Y COMO EL MISMO PDF QUE FELIX CITA MENCIONA EN EL PUNTO 2.3, a veces hay que SACRIFICAR performance para obtener escalabilidad. Y por lo mismo que la escalabilidad depende de la arquitectura y no del lenguaje, un ejemplo sencillo: puedo tener 2 sistemas, uno hecho en java con el modelo de desarrollo clásico, y uno en php con soporte de sharding. Lo mas probable es que el sistema con Java sea mucho mas rápido con una carga de digamos 100 usuarios y 10000 registros. Pero si crecemos a diez millones de usuarios que generan 50 millones de registros AL DIA, el panorama cambia. El sistema clásico con Java va a necesitar un servidor "big-iron" para mantener la carga (si es que la puede soportar). Con el otro sistema con php solo se agregan nodos. Cuál escala mejor? Cuál escala de una manera mas económica? Vuelvo a poner los recursos que recomiendo para los que en verdad quieran profundizar mas en el tema (al menos los 2 primeros libros son algo así como "literatura obligatoria" para escalar algo en internet el día de hoy): - Building Scalable Web Sites[0] - Scalable Internet Architectures[1] - The Art of Capacity Planning[2] Saludos. - - tabo 0- http://oreilly.com/catalog/9780596102357/ 1- http://scalableinternetarchitectures.com/ 2- http://oreilly.com/catalog/9780596518578/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAkoDNFYACgkQywoV1jM0SwMmLwCgqxhLagT5SSjJSdjb2pRKU+mB g5gAnRy1/t+j4c/4Wmay6vtUcw5SaF5Y =/Az7 -----END PGP SIGNATURE----- _______________________________________________ Lista de correo Linux-plug Temática: Discusión general sobre Linux Peruvian Linux User Group (http://www.linux.org.pe) Participa suscribiéndote y escribiendo a: [email protected] Para darte de alta, de baja o hacer ajustes a tu suscripción visita: http://listas.linux.org.pe/mailman/listinfo/linux-plug IMPORTANTE: Reglas y recomendaciones http://www.linux.org.pe/listas/reglas.php http://www.linux.org.pe/listas/comportamiento.php http://www.linux.org.pe/listas/recomendaciones.php
