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