Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Disminuya la carga

Para mejorar los tiempos de respuesta y aumentar los recursos disponibles para los flujos de trabajo críticos, es posible que deba eliminar la carga superflua. Muchas de las soluciones que se tratan en esta sección son decisiones de compensación. Tienen consecuencias para la aplicación y deben considerarse con detenimiento. Puede considerar también estos métodos de estas soluciones en los siguientes casos:

Los cambios inmediatos incluyen los siguientes:

Antes de emprender estas acciones, evalúelas en el contexto de los objetivos y riesgos empresariales a largo plazo.

Cargas de trabajo de lectura y escritura independientes

Una técnica común cuando se ejecutan aplicaciones con tecnología MySQL es descargar las operaciones de lectura de la instancia de base de datos del escritor (principal) y pasarlas a una o más réplicas de bases de datos de solo lectura. Al descargar las lecturas, puede reducir la carga general de la instancia de base de datos principal y dejar espacio para las escrituras. Asegúrese de centrarse únicamente en las lecturas que no dependan de la coherencia inmediata read-after-writepara las réplicas. Un enfoque más eficaz consiste en mover todo el tráfico de lectura a la réplica y planificar la posibilidad de volver a intentarlo read-after-write en caso de que se retrase la replicación. Existen cargas de trabajo de lectura independientes que se pueden reducir, como los servicios de generación de informes. Otras lecturas requerirán cambios en el nivel de la aplicación, donde se conoce bien el contexto por el que se emitió la lectura.

Un enfoque alternativo es implementar una solución proxy de base de datos como intermediaria entre la aplicación y la base de datos, que pueda aportar la función de dividir lectura-escritura y enrutar consultas, sin que la aplicación lo sepa. ProxySQL, MariaDB MaxScale, ScaleARC y Heimdall Data son algunas de las soluciones de proxy compatibles con MySQL disponibles. Estos productos ofrecen varias características adicionales, como el almacenamiento en caché o la multiplexación de conexiones. Cuando experimente un aumento repentino del tráfico e implemente una nueva tecnología en su conjunto de aplicaciones, le recomendamos que comience con la funcionalidad básica de dividir las read/write consultas y probar el comportamiento y el rendimiento antes de utilizar funciones adicionales que podrían tener efectos secundarios no deseados.

Archive o depure los datos antiguos

Otra técnica para mejorar el rendimiento de la base de datos es descargar los datos históricos en otra tabla, base de datos o Amazon Simple Storage Service (Amazon S3). Muchas bases de datos conservan todos los datos en línea durante todo el historial de la aplicación. En circunstancias normales, en una aplicación típica orientada al usuario, esto permite a los usuarios ver todos sus pedidos históricos. Cuando la demanda aumenta repentinamente, es probable que muchos usuarios activen la aplicación sean nuevos o estén centrados en realizar un nuevo pedido. Si los datos históricos se encuentran en línea, en una sola tabla que contiene miles de millones de filas, esto se agrava. Es probable que la tabla también tenga índices grandes. Tanto los datos de la tabla como los índices se almacenan en una estructura de árbol. Tener más entradas en una tabla requiere más niveles en el árbol, lo que requiere más I/O operaciones para acceder a las filas. Esto aumenta el tiempo de acceso para buscar registros individuales. Y lo que es más importante, hace que grandes partes innecesarias del índice residan en la caché de páginas de la base de datos (grupo de búferes de InnoDB).

Archivar los datos antiguos en una tabla independiente, en una base de datos independiente o en Amazon S3 puede reducir los tiempos de acceso de los usuarios finales, liberar memoria caché y mejorar el rendimiento general de las aplicaciones. Archivar los datos antiguos antes del evento (por ejemplo, conservarlos solo durante 30 o 90 días) limita el tamaño de las tablas e índices de las tablas críticas. Este cambio requiere que se modifique la aplicación para consultar los datos más antiguos desde una ubicación secundaria solo para el pequeño subconjunto de usuarios que solicitan explícitamente ver datos históricos.

Aplace los procesos de ETL que no sean críticos

Las extracciones del sistema de base de datos principal para los procesos de ETL pueden suponer un riesgo de estabilidad en el caso de cargas de trabajo simultáneas y con un alto nivel de transacciones en condiciones de hiperescala. Los procesos de ETL son conocidos por las siguientes características:

Procesos de ETL que son variables o impredecibles (por ejemplo, consultas como INSERT INTO ... SELECT FROM ...;) aumentan la variabilidad general de la carga y la contención, lo que aumenta el riesgo de estabilidad.

Siempre que sea posible, aplace o reduzca la frecuencia con la que se ejecutan los procesos de ETL, en especial si no brindan funciones críticas. En el caso de los procesos ETL críticos, modifíquelos para que funcionen en unidades de trabajo limitadas, como procesar lotes de números fijos de filas (por ejemplo, mediante cláusulas LIMIT), usar transacciones independientes o extraer cantidades más pequeñas de datos durante un periodo prolongado, para reducir los picos de demanda de recursos de la instancia de base de datos.

Desactive las características menos críticas de las aplicaciones

Reducir la experiencia del usuario o eliminar características no esenciales al manejar un aumento de solicitudes permite conservar los recursos de la base de datos para las características críticas. Esto puede requerir un leve cambio en la experiencia del cliente, pero un flujo diferente es mejor que el hecho de que el sitio esté inactivo. Quizás pueda deshabilitar de forma temporal la personalización de la página principal del sitio, que siempre hace una llamada a la base de datos. O bien, puede dejar de presentar ofertas personalizadas a los clientes habituales mientras selecciona los productos. La desactivación temporal de las características puede permitir que la página se almacene en caché o se entregue sin necesidad de acceder a la base de datos.

Otros ejemplos incluyen una interfaz con un mecanismo de sondeo que comprueba los cambios en los datos que requieren una llamada a la base de datos. La reducción de la frecuencia de sondeo se traducirá inmediatamente en menos llamadas a la base de datos. Las interfaces de usuario que requieren paginación o que ofrecen a los usuarios la opción de recuperar conjuntos de resultados ordenados más alejados del resultado principal requieren llamadas a las bases de datos cada vez más costosas. Limite el número de páginas de un conjunto de resultados para proteger la base de datos de las llamadas más costosas a la base de datos. Utilice indicadores de características en la capa de aplicación para permitir que el equipo de operaciones desactive o reduzca las características a medida que aumenta la carga de la aplicación o la base de datos.