-----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

Responder a