El vie, 08-05-2009 a las 03:57 -0500, Gustavo Picon escribió: > -----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.
Vaya, aquí sin querer queriendo refrendas las conclusiones del documento en referencia, siendo así, para que redundar tanto?. Aunque ciertamente este es un ejemplo pueril, nótece que la aplicación del criterio o definición 1, apunta a optimizar antes de pasar a aplicar el criterio de modificación de arquitectura entendida como sinónimo de incremento de hardware. > > 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. > El documento es amplio tratando el tema relativo a cuellos de botella, entre otros atribuidos a bases de datos, así como trata el tema de estrategia para alcanzar escalabilidad en tales casos, siempre teniendo a mano tanto la definición 1 como la 2, jamas peyorativizando la definición 1, queda en claro en dicho documento las denominaciones "formal" o "informal" no tienen la finalidad de calificar o descalificar, anteponer una en términos de única interpretación valida de aquello a lo que se alude al utilizar el termino "escalabilidad". > Y es aqui donde la definición informal termina (por eso mencionaba > que no escala). Eso es lo que mencionas tu, es decir es tu interpretación de aquello que se alude al utilizar el termino "escalabilidad", ojo no es lo que se concluye de la lectura del documento en mención ni de los múltiples documentos mencionados en los apéndices. > 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). Ok, pero esa perorata no atañe a lo que es medular o resulta estando en debate, que resulta siendo "aquello a lo que se alude al utilizar el termino o palabra escalabilidad" > > 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 :) Eso es lo ideal, lo alcanzable y deseable es buscar un equilibrio entre lo ideal y lo posible en términos del personal disponible, sus conocimientos, experiencia, presupuesto del que se dispone, etc. > > 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). Cual ciertas partes ni que nada, es cuestión que quien desee lo lea por completa y saque sus conclusiones, el que tomes la parte por el todo debe ser costumbre tuya, imagino. > , esSobre escalabilidad > hay MUCHOS otros recursos bastante mas conocidos (y sobre todo > PRÁCTICOS). Ya he mencionado 3 libros. Para quien tenga interes (interés) > sobre > el tema, aqui (aquí) van algunos recursos más: > La conversación no ha sido forzada por tal o cual documento, que finalmente son entidades inertes, sino por la voluntad de las personas involucradas en la conversación en persistir tenázmente en ella. Como reitero, hay muchas menciones y enlaces a muy buenos documentos en los apéndices, es cuestión que los interesados se tomen el trabajo de buscarlos en internet y les den una leída paciente y reflexiva. > - 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. > Como te lo dije en el canal #apesol: "nadie se desprestigia por actos ajenos, sino por sus propios actos", te lo repito?. Pues si consideras que esto es un circo. simplemente te retiras de la lista y le haces un favor a tu graciosa persona, y tengo que reiterarte nuevamente que no involucres a terceros en tus pleitos personales. Extraído del mismo canal: "00:40 <fmaq> tabo, se mas hombrecito y no involucres a la comunidad en tus desaguisados" "<fmaq> es tu asunto personal, no del resto" Saludos. FMAQ. _______________________________________________ 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
