Ver Mensaje Individual
  #7  
Antiguo 05-02-2014
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Reputación: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Estoy haciendo una cosa parecida (la 2da version de BestSeller) con miras a aguantar un numero ilimitado de usuarios (eso sueño!). Es un cuento mas de arquitectura que del componente per-se, asi que desde el punto de soportar cargas mysql, postgres, firebird, sql server dan igual la talla. La ventaja de postgres esta en sus mejores capacidad generales (es tan capaz como oracle, solo que mucho mas simple) y que puedes programarlo de formas muy variadas. Desde que lo estoy usando, me sorprende cada dia mas - siempre que pienso: Sera que podria hacer esto mejor en PG? la respuesta es siempre si -.

MySql esta mas optimizado para cargas de lecturas, pero como BD para un servicio altamente transaccional PG es mejor.

----

El lio con todo esto es mas como manejar muchos usuarios concurrentes que la cantidad de GB de los datos. PG y cualquier BD funciona muy bien incluso llegando a los terabytes (si tienen el servidor correcto!), asi que el lio es mas como manejar la concurrencia. Y la disponibilidad, y los backups, y todo lo demas.

Hay mucha informacion en este sitio que muestra ideas generales:

http://highscalability.com/blog/2008...ion-users.html
(Este es solo un ejemplo)

Observa este link, de como se escala de forma normal un sitio web (es usando django/python + PG pero la idea es general a cualquier lenguaje), las graficas hacen muy claro el tema:
http://www.djangobook.com/en/2.0/chapter12.html

A nivel general:

- Asegurate que respetas el principio de la programacion "state less"
- No tengas un unico punto de falla. Osea, debes tener al menos un par de TODO. 2+ Servidores web. 2+ Servidores de app. 2+ Instancias de PG, etc. O, que lo pruebes desde el principio asi.
- Como servidor web? nginx. Olvidate de apache. Combina con uwsgi, gunicorn o similar. Aprende como se usa un servidor de cache como memcached y/o redis. No hagas el cache tu mismo! Redis es lo mejor que existe. Memcache es lo que le sigue.
- La BD es la parte mas complicada. Mientras 1 servidor potente te puede dar pa largo, es buena idea tener al menos 2 motores (ej: Un master y un esclavo). Esto no solo es lo sano, sino que ademas simplifica el hacer backups (porque puedes hacerlo contra el esclavo sin poner mas esfuerzo en el equipo que maneja la BD):

http://www.postgresql.org/docs/9.3/i...ilability.html

- No solo debes preocuparte por el servidor web y la BD y creer que eso es todo. Como monitoreas la app? Como obtienes los logs? Como automatizas todo el proceso? Dependiendo de que tan critico sea el tema de la disponibilidad estas cosas se vuelven importantes.

- Usa un proveedor de hosting serio. NO me vayas a desplegar con gente que no sabe o hosting "baratos"!. De entrada: RackSpace, Linode, Microsoft Azure, DigitalOcean (de estos RackSpace & linode tienen mejor fama). son los que te dan mas o menos buen soporte y saben del cuento. Amazon, Google y otros es mas "barato" pero tienes mas responsabilidad (aparte que ni google ni amazon son buenos para nada de nada en soporte, aun si eres un cliente gigante).

- Si quieres lo mas facil que existe: https://www.heroku.com/. Incluso te quitas el dolor de como se administra y escala la BD: https://www.heroku.com/postgres
- Si quieres un poco mas de flexibilidad y control (y poder elegir el proveedor de hosting) entonces https://www.cloud66.com/
Esto es importante en especial si no tienes a la mano gente que sea buen sysadmin. Hacer eso bien es un dolor de cabeza y heroku/cloud66 son la gente que lo simplifica y te permite enfocarte en la programacion. Aun asi, igual tienes que pensar en lo anterior.

A menos que tengas sysadmin que sepan como escalar, administrar y monitorear servidores y todo eso, es mejor que te vayas cpon uin proveedor de cloud.
__________________
El malabarista.

Última edición por mamcx fecha: 05-02-2014 a las 17:52:50.
Responder Con Cita