tips - mysql views performance
¿Qué tamaño puede obtener una base de datos MySQL antes de que el rendimiento comience a degradarse? (14)
Primero me concentraría en sus índices, y luego haría que un administrador del servidor revisara su sistema operativo, y si todo eso no ayuda, podría ser el momento para una configuración maestro / esclavo.
Es verdad. 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 la mire;)
-> Echa un vistazo a la partitioning .
¿En qué momento una base de datos MySQL comienza a perder rendimiento?
- ¿Importa el tamaño físico de la base de datos?
- ¿Importa el número de registros?
- ¿Es alguna degradación del 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. Basándome en estos números, ¿hay algún incentivo para que limpie los datos o estoy seguro de permitir que continúe escalando durante algunos años más?
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 ocupe de todo el conjunto de datos, o incluso de DDL en tablas grandes. Conseguir una importación limpia de un archivo de volcado se ha vuelto problemático. Para que el proceso sea lo suficientemente estable como para automatizarlo, se deben hacer varias elecciones para priorizar la estabilidad sobre el desempeño. Si alguna vez tuviéramos que recuperarnos de un desastre utilizando una copia de seguridad de SQL, estaríamos inactivos durante días.
El escalamiento horizontal de SQL también es bastante doloroso, y en la mayoría de los casos lleva a usarlo de una forma que probablemente no tenía intención cuando eligió poner sus datos en SQL en primer lugar. Los fragmentos, los esclavos leídos, los maestros múltiples, y otros, son soluciones realmente de mierda que añaden complejidad a todo lo que haces con la base de datos, y ninguno de ellos resuelve el problema; Sólo lo mitiga de alguna manera. Le sugeriría encarecidamente que vea cómo mover algunos de sus datos de MySQL (o en realidad cualquier SQL) cuando comience a acercarse a un conjunto de datos de un tamaño en el que este tipo de cosas se convierta en un problema.
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 los índices adecuados, use los motores adecuados (no use MyISAM donde se esperan varios LMD), use la partición, 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.
El tamaño de la base de datos no 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, tendrá problemas de rendimiento si los índices no se configuran correctamente (por ejemplo, no hay índices para los campos en las "declaraciones WHERE" o "condiciones ON" en las combinaciones). 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 del procesador, especialmente la memoria) a menudo ayudan a reducir los problemas más graves al aumentar 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 de Basecamp.
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 blob llena. 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 un gran número de filas por otro lado no es gratis.
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 al que se va a ejecutar 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 contra los esclavos y las consultas de escritura se ejecuten contra 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 puede hacer a la pila de red y al kernel en Linux que ayudarán.
He tenido el mío obtener hasta 10 GB, con solo un número moderado de conexiones y se manejó bien las solicitudes.
Primero me concentraría en sus índices, luego un administrador del servidor revisaría 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. Le 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 caben en 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 sí importa, dependiendo de cómo se vean sus tablas. Es una diferencia tener muchos campos varchar o solo un par de ints o largos.
El tamaño físico de la base de datos también es importante: piense en copias de seguridad, por ejemplo. Dependiendo de su motor, sus archivos db físicos aumentarán, pero no se reducirán, por ejemplo con innodb. Por lo tanto, eliminar muchas filas no ayuda a reducir los archivos físicos.
Hay muchos problemas a este respecto y como en muchos casos el diablo está en los detalles.
Los registros de 2GB y aproximadamente 15M son 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, se trata de un problema de diseño de base de datos / aplicación, no de mysql. uno.
No tiene sentido hablar de "rendimiento de base de datos", "rendimiento de 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 tener una idea de cuántas filas se analizarán y qué índices se usarán con la sintaxis de EXPLAIN.
2GB realmente no cuenta como una base de datos "grande", es más bien un tamaño mediano.
No, en realidad no importa. La velocidad de MySQL es de unos 7 millones de filas por segundo. Así que puedes escalarlo un poco
También ten cuidado con las combinaciones 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 de 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 automóviles, no son datos de consulta relevantes de las posiciones del automóvil en los 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.
Una vez me llamaron para ver 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 2 GB. Y, efectivamente, la tabla que había dejado de aceptar transacciones tenía exactamente 2 GB en el disco. ¡Pero en cuanto 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 siempre hay dimensiones por encima y por debajo de las que naturalmente sospechas.
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. Pongo una consulta para comparar el nombre genérico de medicamentos 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 toma unos segundos.