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

¿En qué punto una base de datos MySQL comienza a perder rendimiento?

  • ¿Importa el tamaño de la base de datos física?
  • ¿Importa el número de registros?
  • ¿Hay alguna degradación de rendimiento lineal o exponencial?

Tengo lo que creo que es una gran base de datos, con aproximadamente 15 millones de registros que ocupan casi 2 GB. Con base en estos números, ¿hay algún incentivo para que limpie los datos, o estoy seguro para permitir que continúe escalando por algunos años más?

El tamaño de la base de datos física no importa. La cantidad de registros no importa.

En mi experiencia, el mayor problema al que te vas a enfrentar no es el tamaño, sino la cantidad de consultas que puedes manejar a la vez. Lo más probable es que tenga que pasar a una configuración maestro / esclavo para que las consultas de lectura puedan ejecutarse contra los esclavos y las consultas de escritura se ejecuten contra el maestro. Sin embargo, si todavía no está preparado para esto, siempre puede ajustar los índices de las consultas que está ejecutando para acelerar los tiempos de respuesta. También hay muchos ajustes que puedes hacer a la stack de red y kernel en Linux que te ayudarán.

He tenido la mía obtener hasta 10 GB, con solo un número moderado de conexiones y se maneja muy bien las solicitudes.

Me centraría primero en sus índices, luego haría que el administrador del servidor revise su SO, y si todo eso no funciona, podría ser el momento de implementar una configuración maestro / esclavo.

En general, este es un tema muy sutil y no trivial en absoluto. Los invito a leer mysqlperformanceblog.com y High Performance MySQL . 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 atender una cantidad razonable de solicitudes con una máquina promedio.

La cantidad de registros importa, dependiendo de cómo se vean sus tablas. Es una diferencia tener muchos campos varchar o solo un par de enteros o largos.

El tamaño físico de la base de datos también importa: piense en copias de seguridad, por ejemplo. Dependiendo de su motor, sus archivos db físicos crecerán, pero no se reducirán, 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, entonces 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 están correctos (por ejemplo, no hay índices para los campos en “Declaraciones WHERE” o “Condiciones ON” en las uniones). Si alcanzas 10 millones de registros, comenzarás a tener problemas de rendimiento incluso si tienes todos tus índices correctos. Las actualizaciones de hardware, que agregan más memoria y más potencia del procesador, especialmente la memoria, a menudo ayudan a reducir los problemas más graves al boost el rendimiento nuevamente, 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 hacer que un administrador de servidor vea su sistema operativo, y si todo eso no ayuda, podría ser hora de una configuración maestro / esclavo.

Es verdad. Otra cosa que generalmente funciona es simplemente reducir la cantidad de datos con los que se trabajó 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 lo mire;)

-> Echa un vistazo a la partición .

2GB y aproximadamente 15M de registros es una base de datos muy pequeña. He ejecutado muchos más grandes en un Pentium III (!) Y todo se ha ejecutado bastante rápido. Si el suyo es lento, es un problema de diseño de base de datos / aplicaciones, no un mysql uno.

No tiene sentido hablar de “rendimiento de la base de datos”, el “rendimiento de la consulta” es un término mejor aquí. Y la respuesta es: depende de la consulta, los datos en los que opera, los índices, el hardware, etc. Puede hacerse una idea de cuántas filas se van a escanear y qué índices se van a utilizar con la syntax de EXPLAIN.

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

También ten cuidado con combinaciones complejas. La complejidad de la transacción puede ser un factor importante además del volumen de transacción.

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

Una vez me pidieron que mirara un mysql que había “dejado de funcionar”. Descubrí que los archivos DB residían en un archivador Network Appliance 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 tenía exactamente 2 GB en el disco. Pero con respecto a la curva de rendimiento, me dijeron que estaba funcionando como un campeón hasta que no funcionó. Esta experiencia siempre me sirve como un buen recordatorio de que siempre hay dimensiones superiores e inferiores a las que naturalmente sospechas.

Un punto a considerar también es 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 la consulta de 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 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 tenga que ver con todo el conjunto de datos, o incluso con DDL en tablas grandes. Obtener una importación limpia de un archivo de volcado se ha vuelto problemático. Para hacer que el proceso sea lo suficientemente estable como para automatizar, se deben hacer varias elecciones para priorizar la estabilidad sobre el rendimiento. Si alguna vez tuviéramos que recuperarnos de un desastre utilizando una copia de seguridad SQL, estaríamos inactivos durante días.

Escalar horizontalmente SQL también es bastante doloroso, y en la mayoría de los casos lleva a usarlo de formas que probablemente no pretendías cuando elegiste poner tus datos en SQL en primer lugar. Shards, read slaves, multi-master, y otros, son todas realmente soluciones de mierda que agregan complejidad a todo lo que haces con el DB, y ninguno de ellos resuelve el problema; solo lo mitiga de alguna manera. Le sugiero encarecidamente que trate de mover algunos de sus datos fuera de MySQL (o realmente cualquier SQL) cuando comience 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 cuestión de miles de filas si la base de datos no está diseñada correctamente.

Si tiene los índices adecuados, usa los motores adecuados (no use MyISAM donde se esperan DML múltiples), use particiones, asigne la memoria correcta según el uso y, por supuesto, tenga una buena configuración de servidor. ¡MySQL puede manejar datos incluso en terabytes!

Siempre hay formas 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 las drogas entre dos tablas. La consulta toma más minutos para ejecutar. Lo mismo, si compara los medicamentos usando el índice de medicamentos, usando una columna de identificación (como se dijo anteriormente), solo lleva unos segundos.

El tamaño de la base de datos SÍ importa en términos de bytes y el número de filas de la tabla. Notarás una enorme diferencia de rendimiento entre una base de datos light y una llena de blobs. 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 los archivos en el disco y poner solo los nombres de los archivos en la base de datos. Iterar una gran cantidad de filas, por otro lado, no es gratis.