¿Qué tan grande puede ser una base de datos MySQL antes de que el rendimiento comience a degradarse

El tamaño de la base de datos física no importa. El número de registros no importa.

En mi experiencia, el mayor problema con el que te vas a encontrar no es el tamaño, sino el número de consultas que puedes manejar a la vez. Lo más probable es que tengas que pasar a una configuración maestro/esclavo para que las consultas de lectura se ejecuten contra los esclavos y las consultas de escritura se ejecuten contra el maestro. Sin embargo, si no estás listo para esto todavía, siempre puedes ajustar tus índices para las consultas que estás ejecutando para acelerar los tiempos de respuesta. También hay un montón de ajustes que puede hacer a la pila de la red y el núcleo en Linux que le ayudará.

El mío ha llegado a 10 GB, con sólo un número moderado de conexiones y ha manejado las solicitudes muy bien.

Me concentraría primero en sus índices, luego haría que un administrador de servidor mirara su sistema operativo, y si todo eso no ayuda, podría ser el momento de implementar una configuración maestro/esclavo.

En general, este es un tema muy sutil y no es trivial en absoluto. Les animo a que lean [mysqlperformanceblog.com][1] y [High Performance MySQL][2]. Realmente creo que no hay una respuesta general para esto.

Estoy trabajando en un proyecto que tiene una base de datos MySQL con casi 1TB de datos. El factor de escalabilidad más importante es la RAM. Si los índices de sus tablas caben en la memoria y sus consultas están altamente optimizadas, puede servir una cantidad razonable de solicitudes con una máquina promedio.

El número de registros sí importa, dependiendo de cómo se vean sus tablas. Es una diferencia tener muchos campos varchar o sólo un par de ints o longs.

El tamaño físico de la base de datos también importa: piensa en las copias de seguridad, por ejemplo. Dependiendo de tu motor, tus archivos físicos de la base de datos crecen, pero no se encogen, por ejemplo con la base de datos. Así que borrar muchas filas no ayuda a reducir los archivos físicos.

Hay mucho que hacer en este tema y, como en muchos casos, el diablo está en los detalles.

[1]: http://mysqlperformanceblog.com [2]: http://www.amazon.com/High-Performance-MySQL-Optimization-Replication/dp/0596101716/ref=pd_lpo_k2_dp_k2a_1_img?pf_rd_p=304485601&pf_rd_s=lpo-top-stripe-2&pf_rd_t=201&pf_rd_i=0596003064&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1KVV0S0YC7DEZFDX5BX3

El tamaño de la base de datos no importa. Si tienes más de una tabla con más de un millón de registros, entonces el rendimiento empieza a degradarse. El número de registros, por supuesto, afecta al rendimiento: [MySQL puede ser lento con tablas grandes][1]. Si llegas a un millón de registros tendrás problemas de rendimiento si los índices no se ajustan correctamente (por ejemplo, no hay índices para los campos en "declaraciones WHERE" o "ON condiciones" en uniones). Si llegas a 10 millones de registros, empezarás a tener problemas de rendimiento incluso si tienes todos los índices correctos. Las actualizaciones de hardware -añadiendo más memoria y más potencia de procesador, especialmente memoria- a menudo ayudan a reducir los problemas más graves al aumentar de nuevo el rendimiento, al menos hasta cierto punto. Por ejemplo, [37 señales pasaron de 32 GB de RAM a 128 GB de RAM][2] para el servidor de la base de datos del Basecamp.

[1]: http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/ [2]: http://37signals.com/svn/posts/1185-the-need-for-speed-making-basecamp-faster

...y la de los demás; Yo me centraría primero en sus índices, que hacer que un administrador de servidor mire su sistema operativo, y si todo eso no ayuda podría ser el momento de una configuración maestro/esclavo.

Eso'es cierto. Otra cosa que suele funcionar es reducir la cantidad de datos con los que se trabaja repetidamente. Si tienes datos antiguos..; y "nuevos datos" y el 99% de tus consultas funcionan con los nuevos datos, sólo tienes que mover todos los datos antiguos a otra tabla - y no los mires ;)

-...-...-...-...-...-..; Echa un vistazo a [partición][1].

[1]: http://dev.mysql.com/doc/refman/5.1/en/partitioning.html

2 GB y unos 15 millones de registros es una base de datos muy pequeña... He ejecutado otras mucho más grandes en un Pentium III... y todo ha seguido corriendo muy rápido... Si el tuyo es lento es un problema de diseño de la base de datos/aplicación, no un problema de mysql.

No tiene sentido hablar de rendimiento de la base de datos; es un término mejor aquí. Y la respuesta es: depende de la consulta, de los datos con los que opera, de los índices, del hardware, etc. Puedes hacerte una idea de cuántas filas se van a escanear y qué índices se van a utilizar con la sintaxis EXPLAIN.

2GB no cuenta realmente como un "grande" base de datos - es más bien de tamaño medio.

Una vez me pidieron que mirara un mysql que había "dejado de funcionar". Descubrí que los archivos de la BD residían en un archivador Network Appliance montado con NFS2 y con un tamaño máximo de 2GB. Y por supuesto, la tabla que había dejado de aceptar transacciones era exactamente 2GB en el disco. Pero con respecto a la curva de rendimiento, me dijeron que funcionaba como un campeón hasta que no funcionó en absoluto. Esta experiencia siempre me sirve como un buen recordatorio de que siempre hay dimensiones por encima y por debajo de las que naturalmente sospechas.

También hay que tener cuidado con las uniones complejas. La complejidad de las transacciones puede ser un gran factor además del volumen de las mismas.

La refactorización de consultas pesadas a veces ofrece un gran impulso al rendimiento.

Un punto a considerar es también el propósito del sistema y los datos en el día a día.

Por ejemplo, para un sistema con monitoreo GPS de autos no es relevante consultar los datos de las posiciones de los autos en los meses anteriores.

Por lo tanto, los datos pueden ser pasados a otras tablas históricas para su posible consulta y reducir los tiempos de ejecución de las consultas del día a día.

Actualmente estoy administrando una base de datos MySQL en la infraestructura de la nube de Amazon que ha crecido a 160 GB. El rendimiento de la consulta está bien. Lo que se ha convertido en una pesadilla son las copias de seguridad, las restauraciones, la adición de esclavos, o cualquier otra cosa que se ocupa de todo el conjunto de datos, o incluso DDL en grandes tablas. Conseguir una importación limpia de un archivo de volcado se ha convertido en un problema. Para que el proceso fuera lo suficientemente estable como para automatizarse, se necesitaban varias opciones para priorizar la estabilidad sobre el rendimiento. Si alguna vez tuviéramos que recuperarnos de un desastre usando una copia de seguridad de SQL, estaríamos muertos durante días.

El escalado horizontal de SQL también es bastante doloroso y, en la mayoría de los casos, lleva a usarlo de maneras que probablemente no tenía intención de hacer cuando eligió poner sus datos en SQL en primer lugar. Los fragmentos, los esclavos de lectura, los multimaestros, etc., son soluciones de mierda que añaden complejidad a todo lo que se hace con la BD, y ninguna de ellas resuelve el problema; sólo lo mitiga de alguna manera. Yo sugeriría fuertemente que se mude algunos de sus datos fuera de MySQL (o realmente cualquier SQL) cuando se empiece a acercar a un conjunto de datos de un tamaño donde este tipo de cosas se convierten en un problema.

El rendimiento puede degradarse en unos pocos miles de filas si la base de datos no está diseñada adecuadamente.

Si tiene índices adecuados, utilice motores adecuados (don'no utilice MyISAM donde se esperan múltiples DMLs), utilice el particionamiento, asigne la memoria correcta dependiendo del uso y por supuesto tenga una buena configuración del servidor, MySQL puede manejar datos incluso en terabytes!

Siempre hay formas de mejorar el rendimiento de la base de datos.

Depende de tu consulta y validación

Por ejemplo, trabajé con una tabla de 100 000 medicamentos que tiene una columna de nombre genérico donde tiene más de 15 caracteres para cada medicamento de esa tabla. Puse una consulta para comparar el nombre genérico de los medicamentos entre dos tablas. La consulta tarda más minutos en ejecutarse. Lo mismo, si se comparan los medicamentos usando el índice de medicamentos, usando una columna de identificación (como se dijo anteriormente), sólo tarda unos pocos segundos.

El tamaño de la base de datos SÍ importa en términos de bytes y número de filas de la tabla. Notará una gran diferencia de rendimiento entre una base de datos ligera y una llena de blob. Una vez mi aplicación se atascó porque puse imágenes binarias dentro de los campos en lugar de mantener las imágenes en archivos en el disco y poner sólo los nombres de los archivos en la base de datos. Por otro lado, la modificación de un gran número de filas no es gratuita.

No, realmente no importa. La velocidad de MySQL es de unos 7 millones de filas por segundo. Así que puedes escalarlo bastante