#9 Pese a que todas las consultas se pueden optimizar, desde la perspectiva de negocio, acabará explotando un día u otro (las peticiones van a subir de forma exponencial en los próximos meses), y prefiero hacer el cambio pronto que tarde. Lo único será que si exprimimos mejor mysql ahora, pues aguantará un tiempo más. (De hecho ahora va perfecto el sistema, pero solo tenemos entre 1 y 10 peticiones por segundo, que es una memez).
Tres posibles clientes nos han pasado estadísticas de uso, y uno de ellos, el más basto, tiene picos de 16000 peticiones por segundo, eso es algo que no aguantamos ni de coña, ni yo, ni mucha gente. El tema es que cada visita que nos pasan implica como mínimo un par de inserciones en la base de datos y 1 select, eso por 16000/s, son 48000 transacciones segundo.
El tema es tenerlo todo previsto para poder escalar horizontalmente de forma rápida y sencilla para cuando pase algo así poder comprar máquinas y añadirlas rápidamente al motor de almacenamiento, y esto es algo que hecho en falta en Mysql (todo el tema del sharding es una movida increíble).
En resumen, me da miedo que todo explote por tener éxito, sería el colmo de la ironía xD
#12 veo que dominas más de nosql. ¿Que características crees que son el punto más desfavorable de estas? Hay posibles pérdidas de datos o inconsistencias? o solo en caso de haberlo programado mal? Ahora mismo gastabamos el motor de mysql MyISAM porque nos sacaba bastante mejor rendimiento, con lo cual no teníamos transacciones tampoco.
Y de todas las implementaciones nosql, con cual te quedarías? mongo, cassandra, redis, hbase? argggg, estoy completamente liado, no sé si lanzarme a por esto, o seguir con mysql + memcache + data sharding...
En definitiva, entre unas cosas y otras mejoramos los tiempos de respuesta en un 90-95%. Y alguien experto lo habría mejorado aún más, segurísimo.
