¿Qué tamaño puede alcanzar una base de datos MySQL antes de que el rendimiento comience a degradarse?

Question

¿En qué momento una base de datos MySQL empieza a perder rendimiento?

• ¿Importa el tamaño físico de la base de datos?
• ¿Importa el número de registros?
• ¿Alguna degradación del rendimiento es lineal o exponencial?

Tengo lo que creo que es una base de datos grande, con aproximadamente 15 millones de registros que ocupan casi 2 GB.Según estos números, ¿hay algún incentivo para que borre los datos o puedo permitir que sigan escalando durante algunos años más?

Answer 1

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

En mi experiencia, el mayor problema con el que se encontrará no es el tamaño, sino la cantidad de consultas que puede 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 en los esclavos y las consultas de escritura en el maestro.Sin embargo, si aún no está preparado para esto, siempre puede modificar sus índices para las consultas que está ejecutando para acelerar los tiempos de respuesta.También hay muchos ajustes que puedes hacer en la pila de red y el kernel en Linux que te ayudarán.

El mío alcanzó hasta 10 GB, con solo una cantidad moderada de conexiones y manejó las solicitudes muy bien.

Primero me centraría en sus índices, luego pediría a un administrador del servidor que revise su sistema operativo y, si todo eso no ayuda, podría ser el momento de implementar una configuración maestro/esclavo.

Answer 2

En general se trata de una cuestión muy sutil y nada trivial.te animo a leer mysqlrendimientoblog.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 caben 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 sí 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 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 muchos problemas en este aspecto y, como en muchos casos, el diablo está en los detalles.

Answer 3

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.Por supuesto, el número de registros afecta el rendimiento: MySQL puede ser lento con tablas grandes.Si alcanza un millón de registros, tendrá problemas de rendimiento si los índices no están configurados correctamente (por ejemplo, no hay índices para los campos en "declaraciones WHERE" o "condiciones ON" en uniones).Si alcanza los 10 millones de registros, comenzará a tener problemas de rendimiento incluso si tiene todos los índices correctos.Las actualizaciones de hardware (agregar más memoria y más potencia de procesador, especialmente memoria) a menudo ayudan a reducir los problemas más graves al aumentar nuevamente el rendimiento, 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.

Answer 4

Me centraría primero en sus índices, luego en pedirle a un administrador del servidor que revise su sistema operativo, y si todo eso no ayuda, podría ser el momento de realizar una configuración maestro/esclavo.

Eso es cierto.Otra cosa que normalmente funciona es simplemente reducir la cantidad de datos con los que se trabaja 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 fraccionamiento.

Answer 5

2 GB y alrededor de 15 millones de registros es una base de datos muy pequeña: he ejecutado bases mucho más grandes en un Pentium III (!) y todo sigue funcionando bastante rápido.Si el suyo es lento, es un problema de diseño de base de datos/aplicación, no de MySQL.

Answer 6

No tiene sentido hablar de "rendimiento de la base de datos", "rendimiento de consultas" es un término mejor aquí.Y la respuesta es:Depende de la consulta, datos sobre los que opera, índices, hardware, etc.Puede hacerse una idea de cuántas filas se escanearán y qué índices se utilizarán con la sintaxis EXPLAIN.

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

Answer 7

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

La refactorización de consultas pesadas a veces ofrece un gran aumento del rendimiento.

Answer 8

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 de archivo máximo de 2 GB.Y efectivamente, la mesa que había dejado de aceptar transacciones tenía exactamente 2 GB en disco.Pero con respecto a la curva de rendimiento, me dijeron que estaba funcionando como un campeón hasta que dejó de funcionar en absoluto.Esta experiencia siempre me sirve como un agradable recordatorio de que siempre hay dimensiones por encima y por debajo de la que naturalmente sospechas.

Answer 9

Un punto a considerar es también la finalidad del sistema y los datos en el día a día.

Por ejemplo, para un sistema con seguimiento GPS de coches no es relevante consultar datos de las posiciones del coche en meses anteriores.

Por tanto los datos se pueden pasar 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.

Answer 10

Actualmente administro 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 tenga que ver con 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.Para que el proceso fuera lo suficientemente estable como para automatizarlo, era necesario tomar varias decisiones para priorizar la estabilidad sobre el rendimiento.Si alguna vez tuviéramos que recuperarnos de un desastre utilizando una copia de seguridad de SQL, estaríamos inactivos durante días.

Escalar SQL horizontalmente también es bastante doloroso y, en la mayoría de los casos, conduce a usarlo de maneras que probablemente no tenía previsto cuando decidió colocar sus datos en SQL en primer lugar.Fragmentos, esclavos de lectura, multimaestro, etc., son todas soluciones realmente malas que agregan complejidad a todo lo que haces con la base de datos, y ninguna de ellas resuelve el problema;sólo lo mitiga de alguna manera.Le sugiero encarecidamente que considere sacar algunos de sus datos de MySQL (o realmente de cualquier SQL) cuando comience a acercarse a un conjunto de datos de un tamaño en el que este tipo de cosas se conviertan en un problema.

Answer 11

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

Si tiene índices adecuados, usa motores adecuados (no use MyISAM donde se esperan múltiples DML), use particiones, asigne la memoria correcta según el 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.

Answer 12

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 en esa tabla. Puse una consulta para comparar el nombre genérico de los medicamentos entre dos tablas. La consulta toma más minutos para ejecutarse. Lo mismo, si compara los medicamentos usando el índice de medicamentos, usando una columna de identificación (como se dijo anteriormente), solo tomará unos segundos.

Answer 13

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 blobs.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 solo los nombres de los archivos en la base de datos.Por otro lado, iterar una gran cantidad de filas no es gratis.

Answer 14

No, realmente no importa.La velocidad de MySQL es de aproximadamente 7 millones de filas por segundo.Entonces puedes escalarlo bastante.