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

En general, este es un tema muy sutil y no trivial en absoluto. Te animo a leer mysqlperformanceblog.com y MySQL de alto rendimiento. Realmente creo que no hay una respuesta general para esto.

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

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

El tamaño físico de la base de datos también importa: piense en las copias de seguridad, por ejemplo. Dependiendo de su motor, sus archivos de base de datos físicos crecen, pero no se reducen, por ejemplo con innodb. Por lo tanto, eliminar muchas filas no ayuda a reducir sus archivos físicos.

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

El tamaño de la base de datos sí importa. Si tiene más de una tabla con más de un millón de registros, el rendimiento comienza a degradarse. El número de registros por supuesto afecta el rendimiento: MySQL puede ser lento con tablas grandes. Si alcanza un millón de registros, obtendrá problemas de rendimiento si los índices no se establecen correctamente (por ejemplo, no hay índices para los campos en "WHERE statements" o "ON conditions" en joins). Si usted golpea 10 millones de registros, usted comenzará a obtenga problemas de rendimiento incluso si tiene todos sus í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 el rendimiento de nuevo, al menos hasta cierto punto. Por ejemplo 37 señales pasaron de 32 GB de RAM a 128 GB de RAM para el servidor de base de datos Basecamp.

Me centraría primero en sus índices, que un administrador del 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 generalmente funciona es reducir la cantidad de datos con los que se ha trabajado repetidamente. Si tiene "datos antiguos" y "datos nuevos" y el 99% de sus consultas funcionan con datos nuevos, simplemente mueva todos los datos antiguos a otra tabla, y no los mire;)

- > Echa un vistazo a particionamiento.

2GB y alrededor de 15M registros es una base de datos muy pequeña - He ejecutado mucho más grandes en un pentium III (!) y todo ha funcionado bastante rápido.. Si el suyo es lento es un problema de diseño de base de datos/aplicación, no uno de mysql.

No tiene sentido hablar de "rendimiento de la base de datos", "rendimiento de la consulta" es un término mejor aquí. Y la respuesta es: depende de la consulta, los datos sobre los que opera, los índices, el hardware, etc. Puede tener una idea de cuántas filas se van a escanear y qué índices se van a usar con la sintaxis de EXPLICACIÓN.

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

También tenga cuidado con las uniones complejas. La complejidad de las transacciones puede ser un factor importante además del volumen de transacciones.

Refactorizar consultas pesadas a veces ofrece un gran aumento del rendimiento.

Una vez me llamaron para ver un mysql que había "dejado de funcionar". Descubrí que los archivos DB residían en un dispositivo de red filer montado con NFS2 y con un tamaño máximo de archivo de 2 GB. Y por supuesto, la tabla que había dejado de aceptar transacciones era exactamente de 2 GB en disco. Pero con respecto a la curva de rendimiento me han dicho que estaba funcionando como un campeón hasta que no funcionó en absoluto! Esta experiencia siempre me sirve como un buen recordatorio de que hay siempre dimensiones por encima y por debajo de la que usted sospecha naturalmente.

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 automóviles no es relevante consultar datos de las posiciones del automóvil en meses anteriores.

Por lo tanto, los datos se pueden pasar a otras tablas históricas para una posible consulta y reducir los tiempos de ejecución de las consultas diarias.

Actualmente estoy administrando una base de datos MySQL en la infraestructura de 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 ocupe de todo el conjunto de datos, o incluso DDL en tablas grandes. Obtener una importación limpia de un archivo de volcado se ha vuelto problemático. Con el fin de hacer que el proceso sea lo suficientemente estable como para automatizar, 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 SQL, estaríamos fuera de servicio durante días.

Escalar horizontalmente SQL también es bastante doloroso, y en la mayoría de los casos conduce a usarlo de maneras que probablemente no pretendía cuando eligió poner sus datos en SQL en primer lugar. Shards, read slaves, multi-master, etc., son soluciones realmente de mierda que agregan complejidad a todo lo que haces con la base de datos, y ninguna de ellas resuelve el problema; solo lo mitiga de alguna manera. Yo sugeriría fuertemente mirando a mover algunos de sus datos fuera de MySQL (o realmente cualquier SQL) cuando comienza a acercarse 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 correctamente.

Si tiene índices adecuados, use motores adecuados (no use MyISAM donde se esperan múltiples DMLs), use particionado, 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 maneras de mejorar el rendimiento de la base de datos.

Depende de su consulta y validación.

Por ejemplo, trabajé con una tabla de 100 000 medicamentos que tiene un nombre genérico de columna donde tiene más de 15 caracteres para cada medicamento en 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 compara los medicamentos utilizando el índice de medicamentos,utilizando una columna de identificación (como se dijo anteriormente), solo toma unos segundos.

El tamaño de la base de datos IMPORTA en términos de bytes y el 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 que 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 solo nombres de archivos en la base de datos. Iterar un gran número de filas, por otro lado, no es gratis.