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

votos
253

¿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?

Publicado el 04/08/2008 a las 15:31
fuente por usuario
En otros idiomas...                            


14 respuestas

votos
169

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 pila 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.

Respondida el 04/08/2008 a las 16:26
fuente por usuario

votos
71

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.

Respondida el 04/08/2008 a las 19:44
fuente por usuario

votos
8

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.

Respondida el 04/08/2008 a las 20:01
fuente por usuario

votos
9

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.

Respondida el 06/08/2008 a las 05:27
fuente por usuario

votos
16

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 sintaxis de EXPLAIN.

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

Respondida el 06/08/2008 a las 20:53
fuente por usuario

votos
20

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 .

Respondida el 11/08/2008 a las 20:19
fuente por usuario

votos
19

2 GB y alrededor de 15 millones de registros es una base de datos muy pequeña - me he encontrado los mucho más grandes en un Pentium III y todo lo que todavía se ha quedado bastante rápido .. Si la suya es lenta es un problema de diseño de base de datos / aplicación, no un mysql (!) uno.

Respondida el 05/08/2010 a las 10:03
fuente por usuario

votos
33

El tamaño de la base de datos tiene importancia . Si usted tiene más de una tabla con más de un millón de discos, entonces el rendimiento comienza efectivamente a degradarse. El número de registros hace, por supuesto, afectará al rendimiento: MySQL puede ser lento con mesas grandes . Si se golpea un millón de registros obtendrá problemas de rendimiento si los índices no se fijan a la derecha (por ejemplo, no hay índices para los campos en "declaraciones donde" u "ON" en condiciones uniones). Si se golpea 10 millones de discos, usted comenzará a tener problemas de rendimiento, incluso si usted tiene todos sus índices derecha. Las actualizaciones de hardware - la adición de más memoria y mayor potencia de proceso, especialmente la memoria - a menudo ayudan a reducir los problemas más graves, aumentando el rendimiento de nuevo, al menos hasta cierto punto. Por ejemplo37 señales fueron de 32 GB de RAM 128 GB de RAM para el servidor de base de datos Basecamp.

Respondida el 26/01/2012 a las 11:33
fuente por usuario

votos
9

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 control por GPS de los coches no es datos de la consulta pertinente de las posiciones de los coches en los meses anteriores.

Por lo tanto, los datos se pueden transmitir a otras tablas históricas para su posible consulta y reducen los tiempos de ejecución del día a día las consultas.

Respondida el 06/12/2012 a las 06:13
fuente por usuario

votos
4

El rendimiento puede degradarse en cuestión de unos pocos miles de líneas que sean la base de datos no está diseñado adecuadamente.

Si tiene índices adecuados, utilizar motores adecuados (no usar MyISAM donde se espera que varios LMD), el uso de particiones, asignar memoria correcta en función del uso y por supuesto tener una buena configuración del servidor, MySQL puede manejar los datos incluso en terabytes!

Siempre hay maneras de mejorar el rendimiento de la base de datos.

Respondida el 19/09/2013 a las 12:26
fuente por usuario

votos
2

Depende de su consulta y validación.

Por ejemplo, trabajé con una mesa de 100 000 drogas que tiene un nombre genérico columna donde cuenta con más de 15 caracteres para cada medicamento en esa mesa .I puso una consulta para comparar el nombre genérico de los medicamentos entre dos consultas tables.The toma más minutos a run.The mismo, si se comparan las drogas usando el índice de drogas, usando una columna de ID (como se ha dicho más arriba), sólo se necesita unos pocos segundos.

Respondida el 29/11/2016 a las 09:05
fuente por usuario

votos
2

Tamaño de base de datos no importa en términos de bytes y el número de filas de la tabla. Usted notará una gran diferencia de rendimiento entre una base de datos ligera y una burbuja llena de uno. Una vez que mi solicitud se atascó porque puse imágenes binarias dentro de los campos en lugar de mantener las imágenes en archivos en el disco y poniendo sólo los nombres de archivo en la base de datos. Iteración a un gran número de filas, por otro lado, no es gratis.

Respondida el 05/06/2017 a las 07:27
fuente por usuario

votos
4

Actualmente estoy gestión de una base de datos MySQL en la infraestructura de la nube de Amazon que ha crecido hasta 160 GB. El rendimiento de consultas está muy bien. Lo que se ha convertido en una pesadilla es copias de seguridad, restauraciones, esclavos, agregando, o cualquier otra cosa que se ocupa de todo el conjunto de datos, o incluso DDL en tablas grandes. Conseguir una importación limpia de un archivo de volcado se ha vuelto problemática. Con el fin de hacer el proceso lo suficientemente estable como para automatizar, diversas opciones necesarias para hacerse dar prioridad a la estabilidad de rendimiento. Si hemos tenido para recuperarse de un desastre utilizando una copia de seguridad de SQL, estaríamos fuera de servicio por día.

Horizontalmente escalar SQL también es bastante doloroso, y en la mayoría de los casos conduce a usarlo de una manera que probablemente no tenía la intención cuando eligió poner sus datos en SQL en el primer lugar. Fragmentos, leen los esclavos, con varios maestros, y otros, que son todas las soluciones de mierda que añaden complejidad a todo lo que haces con el PP, y no uno de ellos resuelve el problema; sólo se mitiga en cierto modo. Me gustaría sugerir fuertemente mirando el traslado de algunos de sus datos de MySQL (o en realidad cualquier SQL) al iniciar acercarse a un conjunto de datos de un tamaño en el que este tipo de cosas se convierten en un problema.

Respondida el 30/06/2017 a las 13:25
fuente por usuario

votos
0

Sin doesnt importa realmente. La velocidad de MySQL es de unos 7 millones de filas por segundo. Por lo que puede escalarla un poco

Respondida el 25/05/2019 a las 12:18
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more