Uso del machine learning para caracterizar las cargas de trabajo de la base de datos

Las bases de datos nos han ayudado a administrar nuestros datos durante décadas. Al igual que gran parte de la tecnología con la que trabajamos a diario, podemos comenzar a darlos por sentado y perder las oportunidades de examinar nuestro uso de ellos, y especialmente su costo.

Por ejemplo, Intel almacena gran parte de su vasto volumen de datos de fabricación en un sistema de gestión de bases de datos relacionales (RDBMS) de procesamiento paralelo masivo (MPP). Para mantener los costos de administración de datos bajo control, Intel decidió evaluar nuestro RDBMS MPP actual contra soluciones alternativas. Antes de que pudiéramos hacer eso, necesitábamos comprender mejor nuestras cargas de trabajo de base de datos y definir un punto de referencia que fuera una buena representación de esas cargas de trabajo. Sabíamos que miles de ingenieros de fabricación consultaban los datos, y sabíamos cuántos datos se estaban ingiriendo en el sistema. Sin embargo, necesitábamos más detalles.

«¿Qué tipos de trabajos componen la carga de trabajo general de la base de datos?»

«¿Cómo son las consultas?»

«¿Cuántos usuarios simultáneos hay para cada tipo de consulta?»

Permítanme presentar un ejemplo para ilustrar mejor el tipo de información que necesitábamos.

Imagina que has decidido abrir un salón de belleza en tu ciudad natal. Desea construir una instalación que pueda satisfacer la demanda actual de servicios, así como acomodar el crecimiento del negocio. Debe estimar cuántas personas estarán en la tienda en la hora pico, para que sepa cuántas estaciones configurar. Debe decidir qué servicios ofrecerá. La cantidad de personas a las que puede servir depende de tres factores: 1) la velocidad a la que trabajan las esteticistas; 2) cuántas esteticistas están trabajando; y 3) qué servicios quiere el cliente (solo un recorte, o una manicura, una coloración del cabello y un masaje, por ejemplo). La «carga de trabajo» en este caso es una función de lo que los clientes quieren y cuántos clientes hay. Pero eso también varía con el tiempo. Tal vez hay períodos de tiempo en los que muchos clientes solo quieren ajustes. Durante otros períodos (por ejemplo, antes del Día de San Valentín), tanto los adornos como la coloración del cabello están en demanda, y sin embargo, en otras ocasiones un masaje puede ser casi la única demanda (por ejemplo, las personas que usan todas esas tarjetas de regalo de masaje que acaban de recibir en el Día de San Valentín). Incluso puede ser aparentemente aleatorio, sin relación con ningún evento del calendario. Si obtiene más clientes en una hora pico y no tiene suficientes estaciones o esteticistas calificadas, la gente tendrá que esperar, y algunos pueden considerarlo demasiado concurrido y alejarse.

Así que ahora volvamos a la base de datos. Para nuestro RDBMS MPP, los «servicios» son los diferentes tipos de interacciones entre la base de datos y los ingenieros (consumo) y los sistemas que están enviando datos (ingesta). La ingesta consiste en extracción-transformación-carga (ETL) estándar, ETL de ruta crítica, cargas masivas y solicitudes de inserción/actualización/eliminación dentro de la base de datos (tanto grandes como pequeñas). El consumo consiste en informes y consultas, algunos se ejecutan como trabajos por lotes, otros ad hoc.

Al comienzo de nuestra caracterización de la carga de trabajo, queríamos identificar los tipos de «servicios» de bases de datos que se estaban realizando. Sabíamos que, al igual que un recorte frente a un servicio completo en el ejemplo del salón de belleza, las solicitudes SQL podrían ser muy simples o muy complejas o en algún punto intermedio. Lo que no sabíamos era cómo generalizar una gran variedad de estas solicitudes en algo más manejable sin perder algo importante. En lugar de confiar en nuestra intuición, queríamos ser metódicos al respecto. Adoptamos un enfoque novedoso para desarrollar una comprensión completa de las solicitudes SQL: decidimos aplicar técnicas de aprendizaje automático (ML) que incluyen:k-significa árboles de agrupamiento y clasificación y regresión (carros).

• k-significa agrupar puntos de datos similares de acuerdo con los patrones subyacentes.
• CART es un algoritmo predictivo que produce un criterio legible por humanos para dividir los datos en subgrupos razonablemente puros.

En nuestro ejemplo de salón de belleza, podríamos usark-significa agrupar y llevar a cabo para analizar a los clientes e identificar grupos con similitudes como «solo servicios para el cabello», «servicios para el cabello y las uñas» y «solo servicios para las uñas».

para nuestra base de datos, nuestrok-Los esfuerzos de Means Clustering y CART revelaron que las solicitudes ETL consistían en siete clústeres (predichos por el tiempo de CPU, la E/S de subprocesos más alta y el tiempo de ejecución) y las solicitudes SQL podían agruparse en seis clústeres (según el tiempo de CPU).

Una vez que tuvimos nuestras agrupaciones, pudimos dar el siguiente paso, que era caracterizar varios períodos pico. El objetivo era identificar algo equivalente a los tipos de carga de trabajo «regular», «justo antes de San Valentín» y «justo después de San Valentín», pero sin saber realmente por adelantado sobre ningún evento del «Día de San Valentín». Comenzamos generando recuentos de solicitudes por cada grupo por cada hora en función de meses de registros históricos de la base de datos. A continuación, utilizamosk-significa agrupar de nuevo, esta vez para crear grupos de franjas horarias de una hora que sean similares entre sí con respecto a sus recuentos de solicitudes por grupo. Finalmente, elegimos algunos espacios de una hora de cada clúster que tenían el mayor uso general de CPU para crear cargas de trabajo de muestra.

Lo mejor de este proceso fue que fue impulsado por datos y conocimientos confiables basados en ML. (Este no es el caso con mi conjetura de solo masajes posteriores a San Valentín, porque no tenía ninguna tarjeta de regalo). La caracterización de la carga de trabajo fue esencial para comparar el costo y el rendimiento de nuestros RDBM MPP existentes y varias alternativas. Puede leer el it@intel documento técnico, «Minimización de los costos de administración de datos de fabricación», para una discusión completa de cómo creamos un punto de referencia personalizado y luego realizamos varias pruebas de concepto con los proveedores para ejecutar el punto de referencia.

Mantente conectado a nuestra revista Channel News Perú, haciendo clic aquí y suscribiéndote a nuestro newsletter para contenido de valor diario.