Cómo el tamaño de la base de datos afecta el rendimiento: teoría versus realidad

Hay muchas cosas que dicen que el tamaño de la base de datos no debería afectar el rendimiento en gran medida. Mientras los índices de las tablas quepan en la memoria, la base de datos debe seguir siendo eficaz.

Sin embargo, ¿cuál es la realidad? Si la arquitectura de la base de datos no es la mejor, los índices no caben en la memoria y potencialmente hay una gran cantidad de datos redundantes. ¿Se pueden obtener ganancias significativas simplemente eliminando datos redundantes? Estimo que 60-80% de los datos en mi base de datos podrían ser eliminados.

Creo que reducir el tamaño de la base de datos y aumentar la RAM para que los índices puedan caber en la memoria daría un aumento significativo en el rendimiento, lo que daría un respiro durante unos meses para volver a diseñar el sistema.

¿Existen otros factores como IO, fragmentación, conjunto de datos de trabajo, etc. que afectan el rendimiento en función del tamaño de la base de datos?

Depende completamente de lo que esté haciendo con los datos.

Para las transacciones básicas de inserción / actualización / eliminación que afectan solo unas pocas filas, entonces el crecimiento en el tamaño de los datos probablemente no sea una gran consideración. La base de datos utilizará índices en memoria para acceder a la página correcta. Obtiene más errores de caché cuando las tablas ya no caben en la memoria. Sin embargo, la sobrecarga puede ser leve, dependiendo de la base de datos, las configuraciones de la base de datos y las configuraciones de hardware.

Si está realizando consultas que requieren escaneos de tabla completa, su rendimiento crecerá linealmente o empeorará con el tamaño de los datos. Los índices pueden empeorar la situación, al aleatorizar los accesos a la página, lo que garantiza la pérdida de caché.

Una alternativa a más memoria es una velocidad de disco mejorada: el disco de estado sólido puede proporcionar una mejora tremenda.

Es poco probable que tener más datos afecte el rendimiento a menos que las tablas se usen en consultas. ¿Son redundantes los datos dentro de una tabla o entre tablas? Tener tablas grandes que nunca se usan es complicado, pero tiene un impacto mínimo en el rendimiento. Es imaginable que si tiene millones de tablas innecesarias, entonces la compilación de consultas podría comenzar a tomar más tiempo.

La regla de ajuste número uno AMM (Agregar más memoria) es simple. También es uno que es muy costoso y al final uno que no es efectivo cuando hay problemas de selectividad. Incluso si una base de datos se ajusta completamente en la memoria, el rendimiento de la aplicación puede ser malo. En el peor de los casos, debido al bloqueo y el enclavamiento durante ejecuciones de SQL muy selectivas. Esos deben arreglarse primero. Una razón es la concurrencia, que es como golpear, y mantener, los descansos si cada SQL accede a todos los datos de una tabla cada vez.

Asegúrese de que ningún SQL acceda a más filas de las necesarias. Esa es la forma más efectiva de mantener un buen rendimiento. Una base de datos normal sabe cómo manejar io y realiza algún tipo de almacenamiento en caché de los datos más utilizados.

Si su aplicación ya ha minimizado todos los accesos posibles y ya utiliza los sistemas de disco más rápidos, considere usar matrices de memoria flash reales. Pueden aumentar el rendimiento en otro nivel.

Por favor, consulte estas publicaciones:

• ¿Qué tan grande puede ser una base de datos MySQL antes de que el rendimiento comience a degradarse?
• ¿Por qué MySQL podría ser lento con tablas grandes?

Consejos para hacer que sus datos sean lo más pequeños posible:

Diseñe sus tablas para minimizar su espacio en el disco. Esto puede generar grandes mejoras al reducir la cantidad de datos escritos y leídos del disco. Las tablas más pequeñas normalmente requieren menos memoria principal mientras su contenido se procesa activamente durante la ejecución de la consulta. Cualquier reducción de espacio para los datos de la tabla también da como resultado índices más pequeños que pueden procesarse más rápido.

MySQL admite muchos motores de almacenamiento diferentes (tipos de tabla) y formatos de fila. Para cada tabla, puede decidir qué método de almacenamiento e indexación usar. Elegir el formato de tabla adecuado para su aplicación puede brindarle una gran ganancia de rendimiento.

Puede obtener un mejor rendimiento para una tabla y minimizar el espacio de almacenamiento utilizando las técnicas enumeradas aquí: - Utilice los tipos de datos más eficientes (más pequeños) posibles. MySQL tiene muchos tipos especializados que ahorran espacio en disco y memoria. Por ejemplo, use los tipos enteros más pequeños si es posible para obtener tablas más pequeñas. MEDIUMINT suele ser una mejor opción que INT porque una columna MEDIUMINT utiliza un 25% menos de espacio.

• Declare que las columnas NO SON NULAS si es posible. Hace que todo sea más rápido y ahorras un bit por columna. Si realmente necesita NULL en su aplicación, definitivamente debe usarlo. Simplemente evite tenerlo en todas las columnas de forma predeterminada.

• Para las tablas MyISAM, si no tiene columnas de longitud variable (columnas VARCHAR, TEXT o BLOB), se utiliza un formato de fila de tamaño fijo.

• Las tablas InnoDB usan un formato de almacenamiento compacto. En las versiones de MySQL anteriores a 5.0.3, las filas de InnoDB contienen información redundante, como el número de columnas y la longitud de cada columna, incluso para columnas de tamaño fijo. Por defecto, las tablas se crean en formato compacto (ROW_FORMAT = COMPACT). La presencia del formato de fila compacto disminuye el espacio de almacenamiento de fila en aproximadamente un 20% a costa de aumentar el uso de la CPU para algunas operaciones. Si su carga de trabajo es típica y está limitada por las tasas de aciertos de caché y la velocidad del disco, es probable que sea más rápida. Si es un caso raro que está limitado por la velocidad de la CPU, podría ser más lento.

El formato compacto InnoDB también cambia la forma en que se almacenan las columnas CHAR que contienen datos UTF-8. Con ROW_FORMAT = REDUNDANT, un CHAR UTF-8 (N) ocupa 3 × N bytes, dado que la longitud máxima de un carácter codificado UTF-8 es de tres bytes. Muchos idiomas se pueden escribir principalmente utilizando caracteres UTF-8 de un solo byte, por lo que una longitud de almacenamiento fija a menudo desperdicia espacio. Con el formato ROW_FORMAT = COMPACT, InnoDB asigna una cantidad variable de almacenamiento en el rango de N a 3 × N bytes para estas columnas eliminando espacios finales si es necesario. La longitud mínima de almacenamiento se mantiene como N bytes para facilitar las actualizaciones in situ en casos típicos.

• El índice primario de una tabla debe ser lo más corto posible. Esto hace que la identificación de cada fila sea fácil y eficiente

• Cree solo los índices que realmente necesita. Los índices son buenos para recuperar pero malos cuando necesita almacenar datos rápidamente. Si accede a una tabla principalmente buscando en una combinación de columnas, cree un índice sobre ellas. La primera parte del índice debería ser la columna más utilizada. Si siempre usa muchas columnas al seleccionar de la tabla, la primera columna del índice debe ser la que tenga más duplicados para obtener una mejor compresión del índice.

• En algunas circunstancias, puede ser beneficioso dividir en dos una tabla que se escanea con mucha frecuencia. Esto es especialmente cierto si se trata de una tabla de formato dinámico y es posible utilizar una tabla de formato estático más pequeña que se puede utilizar para encontrar las filas relevantes al escanear la tabla.