Eso de que 30 millones de datos en una tabla no es demasiado es cuanto menos discutible. Con índices está claro que mejora, incluso salen resultados casi de inmediato. El problema es que no vas a crear un índice para cada columna (o al menos no deberías...). En el momento en que tengas que cruzar una tabla de 30 millones con otras 4 o 5 tablas que estén relacionadas, el rendimiento no va a ser bueno.
Actualmente trabajo para un proyecto en el que tenemos lecturas de luz de los clientes. Como podéis imaginas, hay varios millones de registros para esa tabla... y las consultas que tienen que cruzar con esas tablas, son bastante lentas... hablamos de lentitud varios segundos, desde luego la respuesta no es inmediata... a no ser que busquemos por los índices que es bastante rápida. Pero en nuestro caso, podemos hacer búsquedas por varios campos de esa tabla y por campos que están en otras tablas con las que se cruza...
Respuesta inmediata, para mi, complicado.
Por cierto, en mongoDB también hay indices y demás, pero como no es relacional, obviamente no hay PK hacia otras tablas. La verdad es que la organización del modelo de datos en una BBDD no relacional cambia mucho con respecto a una relacional. A mi me sigue costando ver que muchas veces esa organización sea mejor, pero muchas veces, se mete todos los datos del tirón en el documento, es decir, en vez de separar en varias tablas, se mete todo el contenido en el mismo documento. Según explicaban los de mongo, puede parecer que es mala solución por la manera de pensar que tenemos, que vamos a tener datos repetidos muchas veces... pero que la memoria física hoy en día es barata (razón no les falta) y que hay que ir mas allá, pensar en cuantas veces actualizaríamos esos datos extras que metemos. Un ejemplo chorra, si tienes que organizar libros y autores, la alternativa natural es meter los autores en una tabla, los libros en otra y que esta últiam tenga un PK hacia los autores. En mongo se puede hacer así (sin PK como tal) o también añadir la información de los autores a los libros directamente. ¿Qué va a tener muchas veces los datos de un autor, pues sí. Pero si estamos guardando 3 campos de los autores, lo mismo nos merece la pena. ¿Que si hay que hacer un update hay que recorrer todos los libros para actualizar 100 veces el mismo autor?. Pues sí, ¿cuántas veces se actualizarán los registros de este catálogo?. Cambia mucho la menra de enfocar los problemas con una BBDD relacional o no relacional. Por ejemplo, nosotros hicimos una especie de blog y la recomendación fue que los comentarios de los post guardaran en ellos mismos el autor del comentario, en vez de organizarlo por fuera en otra tabla. Es curioso y un poco extraño :S
Saludos
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
Siguiendo el ejemplo de Facebook, ellos no solo tienen su propio fork de mysql ultra-tuneado sino que también diseñan su propio hardware.![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
