Listo! ya updateé http://wiki.linux.org.pe/Escalabilidad con el nuevo correo ;)
Tabo: gracias por toda la info :) Jorge S. 2009/5/8 Gustavo Picon <[email protected]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On May 7, 2009, at 4:54 PM, Antonio Ognio wrote: >> El día 7 de mayo de 2009 16:21, Gustavo Picon >> <[email protected]> escribió: >>> Por mi parte no. Tengo que lidiar con problemas de escalabilidad a >>> diario :) >> >> Tabo, al parecer, con el PDF que Felix ha enviado, el está tratando de >> demostrar que cuando afirmó que "X tecnología no escalaba" (ya ni me >> acuerdo cual era) estaba haciendo un uso razonable del término ya que >> se encuentra con frecuencia en la práctica diaria de profesionales de >> IT y no es necesariamente incorrecto. A mi Felix casi me ha convencido >> de que no ha incurrido en un error, especialmente comprendiendo que el >> ha hecho esta intervención en la lista LUEGO de haber leido (y estar >> influcenciado) por el texto al que hace referencia. > > Toño, la mayoría de profesionales de IT piensa que linux es una > "pantallita negra", que windows esta escrito en visual basic, que Bill > Gates inventó internet y que subversion era lo que hacía sendero. Que > algo sea de uso común no lo hace correcto, y justamente por eso: > > 1- el pdf (que si bien es interesante es puramente teórico) > menciona que esta es una definición INFORMAL (y limitada), pero que > se incluye porque es de uso común (ya lo verás cuando lo leas). > > 2- lo que vengo sosteniendo es, y como el ya famoso pdf confirma, > performance y escalabilidad NO SON lo mismo. > > A lo que voy es: > > a) Puedo tener un sistema MUY LENTO que escala MUY BIEN. El clåsico > ejemplo es: > > <?php > sleep(1); > echo "Hello world!"; > ?> > > El programa es lento, se demora UN SEGUNDO en tan solo imprimir un, > hello world, pero escala muy bien. Un solo servidor puede atender > MUCHAS de estas peticiones (definición informal), o si la carga > aumenta demasiado y el primero servidor ya no escala, podemos > agregar servidores adicionales (definición formal). Ambas > definiciones se cumplen sin alterar la arquitectura. > > b) Puedo tener un sistema MUY RAPIDO que escala POBREMENTE. Ejemplo? > una > solución que hace un uso típico de base de datos (normalización, > joins, unos triggers por ahi, un par de stored procedures). Puede > ser > un balazo con pocos usuarios/data, y va a crecer bien (definición > informal) hasta cierto punto, pero cuando este servidor ya no > aguante > el load (que normalmente no es O(n) si no O(n^2) o peor), > tienes que alterar la arquitectura. > > Y es aqui donde la definición informal termina (por eso mencionaba > que no escala). Es aquí donde empieza a ser necesario usar caches > de > datos, a denormalizar, a hacer tablas resúmenes, a hacer table > partitioning, a hacer replication, a hacer MUCHO replication, a > tomar medidas para no patinar con el replication lag, a llegar al > límite del replication porque los writes no escalan como los reads, > a separar tablas a otra base de datos. Y cuando una tabla gigante > es demasiada carga para un solo servidor, empezamos a hacer > federation, a hacer sharding. A odiar el modelo relacional. A > volver > el sistema asíncrono. A instalar un sistema de colas. A empezar a > averiguar que hash based db parece mas estable. A planificar > proyectos que permitan usar un DBMS como un hash based db :) > > Este sistema no escala tan bien como el anterior: para que soporte > mas carga, tengo que cambiar su arquitectura. (Y esa serie de pasos > que he citado son los mas usuales para hacer escalar la db). > > Entonces la cosa básicamente va por ahi. Que tengas buena performance > no significa que escales. Puedes tener un sistema lento que escala > bien, como puedes tener un sistema rápido que escala mal. Obviamente > lo ideal es tener un sistema MUY RAPIDO que escale MUY BIEN, y es ahi > donde entra la ingeniería y la cosa se pone interesante :) > > Ahora, un lenguaje influye mucho en performance. No en el diseño de la > arquitectura. Que tu capa de negocios esté en python o java no va a > alterar en gran manera la manera como haces el sharding en la bd, o > como vas a manejar las colas. > > Otra cosa, la conversación ha sido prácticamente forzada sobre un solo > documento (y en realidad solo a ciertas partes). Sobre escalabilidad > hay MUCHOS otros recursos bastante mas conocidos (y sobre todo > PRÁCTICOS). Ya he mencionado 3 libros. Para quien tenga interes sobre > el tema, aqui van algunos recursos más: > > - High Scalability[0]: Un blog que tiene artículos interesantes > (aunque últimamente la calidad ha bajado bastante), pero cuyo > principal > atractivo es la serie "Real Life Architectures"[1]. > > - La presentación sore la arquitectura de Ebay[2]. > > - La presentación de Cuong Do sobre como escalaron Youtube[3] (en la > que > cuenta los growing pains que tuvieron y como salieron adelante). > > - Una presentación FASCINANTE de Aditya Agarwal sobre como hace > facebook > para escalar (como sus 1800 servidores mysql administrados por DOS > dbas). > > Para terminar, y como le comentaba ayer a Diego Escalante, en lo > personal siento un poco de responsabilidad por todos los alumnos a los > que he recomendado entrar a esta lista. Es por eso que al menos trato > de explicar algo correctamente. Para beneficio de la lista, no para > prestarme a un circo. > > > Saludos. > > [0]- http://highscalability.com/ > [1]- http://highscalability.com/links/weblink/24 > [2]- http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf > [3]- http://video.google.com/videoplay?docid=-6304964351441328559 > [4]- http://www.infoq.com/presentations/Facebook-Software-Stack > > - - tabo > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.11 (Darwin) > > iEYEARECAAYFAkoD9AUACgkQywoV1jM0SwMtfQCbBF6a0jnmEvN1++JpW180MVuK > TJwAnjvV7eKE+cofymZTk+2cFpaSYmOq > =f+Hi > -----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 > _______________________________________________ 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
