PHP + MYSQL con millones de registros

Aquí abro un nuevo tema relacionado con bases de datos MySQL con grandes volúmenes de datos (millones de registros)

Me acaban de pasar un proyecto ya desarrollado que tiene problemas de rendimiento y el soporte de su servidor les dice “El cuello de botella parece venir del acceso a disco. Creemos que en este caso puede deberse a la saturación de MySQL, ya que vemos que tienen tablas con más de 1 millón de registros, lo que puede ocasionar problemas.”

He navegado por la red, y veo que efectivamente esto puede suponer un problema para MySQL, pero también tengo entendido que sistemas cómo Twitter o Facebook que pueden manejar millones de registros en sus inicios al menos usaban MySQL. Entonces mi duda es, ¿cuál sería el planteamiento? He leído a cerca de NoSQL al respecto..

Me estoy mirando la ayuda de MySQL y diversas opiniones y comentarios que hay en la red, pero quiero consultarlo con vosotros, que hasta ahora habéis sido un aporte valiosísimo. También lo quiero dejar aquí, por si el día de mañana le vale a otro.

Bueno, vayamos al grano:

1.- Tengo claro la importancia de revisar el esquema de la BD, las consultas, así como índices y claves, etc. (sql query log, y explain me vienen de maravilla)

2.- La cache de página, de base de datos, etc.. para no sobrecargar la base de datos si hay muchas visitas concurrentes.

Hasta ahí bien (avisadme si no me dejo nada importante).
¿Ahora por dónde seguir? ¿Me dejo algo?

Y por ponernos en un ejemplo real, en este caso veo una tabla “productos” con casi 1/2 millón de filas, y una relacionada que es “imagenes”, que tiene 5 millones de imágenes. Un producto tiene de 1 a N imágenes, siendo la media por lo veo aproximadamente 10. Por cada imagen solo se guarda un id, y una ruta al archivo físico.

¿Sería más eficiente para la base de datos pasar las imágenes de cada producto a una columna de la tabla productos? ¿Cuál es vuestra opinión? (estoy haciendo pruebas con este ejemplo)

Y por otro lado veo estos libros/recursos veo:
http://shop.oreilly.com/product/0636920022343.do
http://shop.oreilly.com/product/0636920026907.do
http://shop.oreilly.com/product/0636920000136.do

¿Alguien me recomienda más?

Y sobre todo, gracias de antemano!

albertodiez1984 escribió:

NO.

Eso alargaría el archivo físico de la tabla haciendo más lento su acceso, además tienes la penalización por lectura de blob por parte de MySQL. Esto definitivamente es un "no, no lo hagas".

Supongo que te lo han dicho pero por la dudas: Busca de optimizar las consultas SQL para que devuelvan la menor cantidad de registros posibles con la menor cantidad de campos. Además trata de simplificar las consultas que contienen subconsultas, o sea las del tipo SELECT * FROM (SELECT * FROM...)...

Debes aprender a normalizar las tablas.. es decir a no repetir datos en una sola tabla.

Busca por normalización. Aunque aumentas el número de tablas, debido a que indexas más contenido, los algoritmos de MySQL se vuelven más eficientes.

No explicaré el porque detalladamente, es aburrido.. pero imaginate un diccionario.. no vas buscando palabra por palabras.. si no letra por letra, en fin algo asi.

Que sea una base de datos más pesada, no significa que sea menos eficiente.