Aplicación MUY GRANDE - CloudComputing

hola foro, les mando saludos

Necesito hacer una aplicación web que va a recibir mucha carga (3,000,000) registros al mes o más, necesito mantenerla siempre disponible en internet por lo que tengo pensado meterla como cloud computing, no conozco nada del tema pero he visto que está por ejemplo amazon y google pero algunas aplicaciones tienen incompatibilidades al montarlas a la nube o tienes que desarrollar con ciertas librerías o frameworks para que jale....

1. ¿Qué framework web me recomiendan?
2. Qué otras alternativas tengo aparte de cloud computing?, creen que puedo contratar servidores dedicados y yo mismo configurar los balanceadores de carga o me conviene más meter cloud computing y me quito de ese problema?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

no es tanto

Generar 3M de registros al mes no es tanto... son 100mil diarios en promedio. Con un RDBMS dedicado y un app server dedicado no debes tener problema, pero pues es el costo de hospedar 2 servidores, más tener 2 servidores. Puedes ver algo como rackspace, que es medio nube y medio como servidores dedicados, porque no tienes que programar nada en especial, puedes hacer tu aplicación de la manera tradicional y en rackspace configuras lo que necesites para que corra bien tu app con base de datos y el contenedor que tú quieras. Dependiendo de la naturaleza de tu aplicación, incluso podrías darte abasto con un solo contenedor, o si piensas tener muchas consultas y son en aplicaciones distintas, podrías poner un contenedor con las apps que generan los datos y hacen transacciones, y otro contenedor en otro equipo o nodo para las aplicaciones que hacen puras consultas (reportes generalmente).

Para nube, en Java, revisa Google App Engine y CloudFoundry. Seguramente hay otras opciones pero esas son las que yo he visto y he considerado para usar, aunque todavía no tengo nada corriendo en ninguna nube.

Lo importante es que evalúes muy bien las opciones de acuerdo a los requerimientos de tu aplicación, y no que te vayas por la nube sólo porque está de supermoda y lo mencionan en todas las revistas y que quieras poner NoSQL porque todos los chicos cool lo usan (o dicen que lo usan, pero quién sabe para qué lo usen realmente). Si necesitas ACID en tus transacciones, no recomiendo NoSQL, más bien una RDBMS como PostgreSQL o de plano algo comercial como Oracle o DB2, SQLServer, etc.

No es lo mismo que se pierdan de repente unas visitas en foursquare a que se pierdan unas ventas o que algunos saldos no cuadren porque tu base de datos es "eventualmente consistente" por que algunas consultas dan resultados temporalmente inconsistentes.

Uso de la sesión

Gracias por la respuesta, voy a revisar los puntos que me mencionas...
Hay 2 cositas más que me intrigan mucho:

A qué se le podría llamar muchos registros ? Espero que la aplicación comience con ese número de registros pero vaya creciendo y eso me causa un poco de ruido en la cabeza

La segunda es acerca de cómo usar la sesión en mi aplicación, realmente no se si hacer uso paranoico del request y evitarme la sesión lo más que pueda para no tener problemas de rendimiento, quiero evitar dolores de cabeza con los datos en la sesión....

Gracias nuevamente por tu tiempo y tus comentarios

Imagen de ezamudio

carga, consultas

Yo le llamaría muchos registros a generar por ejemplo 1 millón de registros diarios, sobre todo si hay que estarlos consultando constantemente. Si hay que guardar datos viejos, digamos un año, porque entonces puedes tener hasta 360M de registros en una tabla... dependiendo de la base de datos que uses (y los fierros donde corre) eso puede ser ya demasiado o puede atenderlo bien. Depende también de las consultas que haces, de que tengas algunos caches en tus aplicaciones, de que la tabla se encuentre bien indexada y particionada, etc.

Si quieres probar otra opción de datos, acabo de ver esta opción de GemFire que parece interesante.