¿En qué punto una base de datos MySQL comienza a perder rendimiento?
Tengo lo que creo que es una gran base de datos, con aproximadamente 15 millones de registros que ocupan casi 2 GB. Según estos números, ¿hay algún incentivo para que limpie los datos o estoy seguro de permitir que continúe escalando por unos años más?
Respuestas:
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 te vas a encontrar 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 contra el maestro. Sin embargo, si aún no está listo para esto, siempre puede ajustar sus índices para las consultas que está ejecutando para acelerar los tiempos de respuesta. También hay muchos ajustes que puede hacer a la pila de red y al núcleo en Linux que ayudarán.
He tenido el mío hasta 10 GB, con solo un número moderado de conexiones y manejó bien las solicitudes.
Me centraría primero en sus índices, luego pediría a un administrador del servidor que mire 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 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 se ajustan a la memoria y sus consultas están altamente optimizadas, puede atender una cantidad razonable de solicitudes con una máquina promedio.
El número de registros es importante, 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 es importante: piense en las copias de seguridad, por ejemplo. Dependiendo de su motor, sus archivos db físicos crecen, pero no se reducen, por ejemplo con innodb. Por lo tanto, eliminar muchas filas no ayuda a reducir los archivos físicos.
Hay muchos problemas con esto 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 llega a 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 "Declaraciones WHERE" o "Condiciones ON" en las uniones). Si alcanza los 10 millones de registros, comenzará a tener problemas de rendimiento incluso si tiene todos sus índices correctos. Las actualizaciones de hardware, que agregan 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 en cierto grado. Por ejemplo37 señales pasaron de 32 GB de RAM a 128 GB de RAM para el servidor de base de datos Basecamp.
Me enfocaría primero en sus índices, que hacer que un administrador del servidor revise 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 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 .
No tiene sentido hablar sobre "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 con los que opera, los índices, el hardware, etc. Puede hacerse una idea de cuántas filas se escanearán y qué índices se usarán con la sintaxis EXPLAIN.
2GB realmente no cuenta como una base de datos "grande", es más bien de tamaño mediano.
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. Para que el proceso sea lo suficientemente estable como para automatizar, se deben 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 horizontalmente SQL también es bastante doloroso y, en la mayoría de los casos, lleva a usarlo de una manera que probablemente no tenía la intención cuando eligió poner sus datos en SQL en primer lugar. Fragmentos, esclavos leídos, multimaestro, etc., son soluciones realmente 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. Sugeriría encarecidamente que busque 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 en el que este tipo de cosas se convierten en un problema.
También ten cuidado con las combinaciones complejas. La complejidad de la transacción puede ser un factor importante además del volumen de la transacción.
Refactorizar consultas pesadas a veces ofrece un gran impulso de rendimiento.
Una vez me llamaron para mirar un mysql que había "dejado de funcionar". Descubrí que los archivos DB residían en un archivador de Network Appliance montado con NFS2 y con un tamaño máximo de archivo de 2GB. Y efectivamente, la tabla que había dejado de aceptar transacciones era exactamente de 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ó en absoluto! Esta experiencia siempre me sirve como un buen recordatorio de que siempre hay dimensiones superiores e inferiores a las que sospechas 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.
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 DML), use particiones, asigne 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 una columna de nombre genérico donde tiene más de 15 caracteres para cada medicamento en esa tabla. Realicé una consulta para comparar el nombre genérico de los medicamentos entre dos tablas. más minutos para correr. Lo mismo, si compara las drogas usando el índice de drogas, usando una columna de identificación (como se dijo anteriormente), toma solo unos 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ás una gran diferencia de rendimiento entre una base de datos ligera 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 guardar imágenes en archivos en el disco y poner solo nombres de archivos en la base de datos. Iterar una gran cantidad de filas por otro lado no es gratis.
No, realmente no importa. La velocidad de MySQL es de aproximadamente 7 millones de filas por segundo. Entonces puedes escalarlo un poco
El rendimiento de la consulta depende principalmente de la cantidad de registros que necesita escanear, los índices juegan un papel importante y el tamaño de los datos del índice es proporcional a la cantidad de filas y la cantidad de índices.
Las consultas con condiciones de campo indexadas junto con el valor completo se devolverían en 1 ms en general, pero comienza_con, IN, Between, obviamente contiene condiciones que pueden tomar más tiempo con más registros para escanear.
También enfrentará muchos problemas de mantenimiento con DDL, como ALTER, DROP será lento y difícil con más tráfico en vivo incluso para agregar un índice o nuevas columnas.
En general, es aconsejable agrupar la base de datos en tantos grupos como sea necesario (500 GB sería un punto de referencia general, como dicen otros, depende de muchos factores y puede variar según los casos de uso) de esa manera proporciona un mejor aislamiento y da independencia a la escala específica clusters (más adecuados en el caso de B2B)