Estoy creando una aplicación web acortadora de URL y me gustaría saber cuál es la mejor arquitectura para hacerlo a fin de brindar un servicio rápido y confiable.
Me gustaría tener dos servicios separados en máquinas diferentes.
- La primera máquina tendrá la aplicación en sí con apache, nginx, lo que sea.
- El segundo contendrá la base de datos.
- El tercero será el que se encargará de gestionar las peticiones de URL cortas.
ACTUALIZAR:
El servicio no es un acortador de URL en absoluto. Simplemente era más fácil explicarlo así.
Sólo necesito una máquina que reciba una consulta http e inserte un registro en una base de datos. Y necesito esta máquina para realizar esta sencilla tarea de una manera muy eficiente. El sistema se ejecutará en Linux (aún no conozco la distribución) y estoy totalmente abierto a cualquier lenguaje o tecnología. Estaba pensando en usar Yaws, Tornado o Snap para ese servicio, pero aún no lo sé y es hora de planificar la arquitectura para esa parte. La base de datos se construirá en Hadoop.
Para la tercera máquina sólo necesito aceptar un tipo de petición http (GET www.domain.com/shorturl), pero tiene que hacerlo muy rápido y debe ser lo suficientemente estable.
Respuesta1
¿Realmente crees que es necesario otro acortador de URL? solo hayTantosde ellos... a menos que por casualidad haya logrado adquirir un nombre de dominio muy corto y apropiado, no creo que nadie se dé cuenta de su sitio. Sólo mi granito de arena, por supuesto.
En fin, a la parte técnica:
- ¿En qué idioma vas a escribir tu solicitud?
- ¿En qué sistema operativo planeas ejecutarlo?
- ¿Usarás software gratuito o comercial?
Es difícil responder a tu pregunta sin siquiera saberlo.
La única respuesta que puede tener sentido aquí es "evitar Java como una plaga". Un servidor de aplicaciones Java es excesivo para muchas aplicaciones, y seguramente lo sería para una tan simple.
Yo elegiría Linux/Apache/MySQL/PHP aquí...siPor supuesto, se me ocurre cualquier buena razón para iniciar el proyecto.
Editar:
Bien, ahora tiene un poco más de sentido; pero la sugerencia de empezar lo más simple posible yentoncesla preocupación por la ampliación sigue siendo válida. Si su aplicación es realmente así de simple, cualquier combinación decente de servidor web/idioma/base de datos debería poder procesarlotesde solicitudes por segundo en hardware moderno (pero aún así recomiendo encarecidamente evitar Java).
Si el rendimiento es primordial, optaría por una aplicación CGI escrita en C;esoserá la solución más rápida posible, órdenes de magnitud más rápida que cualquier lenguaje interpretado o VM; y hacer que haga INSERTS y SELECT simples en una base de datos no debería serentoncesdifícil. Pero creo que LAMP es más que suficiente para tus necesidades... en realidad funcionanFacebooken ello, ¿sabes?
Respuesta2
¿Son sólo datos de registro o también envían algo de interés? Si solo están iniciando sesión, entonces simplemente use apache y arroje los registros de apache a hadoop. Si tienen que devolver algún tipo de datos, entonces no me queda del todo claro cómo obtienen los datos que están devolviendo.
Aún así, Apache configurado para devolver simplemente un archivo estático para cualquier solicitud es bastante rápido.
Respuesta3
Primero, sé que dijiste que no es un acortador de URL, pero si es algo similar, un RDBMS es una forma terrible de almacenar estos datos; Dado que no existe una relación real entre dos datos, desea un motor de almacenamiento plano. Considere Mongo (o Couch, según el espacio de su solución real).
En cuanto a su solución, tenga cuidadooptimización prematura. Hay muchas maneras de volverse loco con esto; Como preguntaste, lo más loco que se me ocurre podría ser iniciar Varnish, escribir todas tus páginas en VCL y hacer que se conecte a Memcache en el backend para almacenar y recuperar los datos correspondientes. Pero siendo realistas, eso esmierdaloco a menos que estés bajo cargas evidentemente absurdas.