Uso del aprendizaje automático para caracterizar cargas de trabajo de bases de datos

Jun 27, 2023

Las bases de datos nos han ayudado a gestionar nuestros datos durante décadas. Como gran parte de la tecnología con la que trabajamos a diario, podemos comenzar a darla por sentado y perder oportunidades de examinar nuestro uso, 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 masivo paralelo (MPP). Para mantener los costos de administración de datos bajo control, TI de Intel decidió evaluar nuestro MPP RDBMS actual frente a soluciones alternativas. Antes de poder hacer eso, necesitábamos comprender mejor las cargas de trabajo de nuestras bases de datos y definir un punto de referencia que sea 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 constituyen 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 presentarles 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. Quiere construir una instalación que pueda satisfacer la demanda actual de servicios y adaptarse al crecimiento empresarial. Debe estimar cuántas personas habrá en la tienda en el momento pico, para saber cuántas estaciones configurar. Debe decidir qué servicios ofrecerá. La cantidad de personas a las que puedes atender depende de tres factores: 1) la velocidad a la que trabajan las esteticistas; 2) cuántas esteticistas están trabajando; y 3) qué servicios desea el cliente (solo un corte, o una manicura, una coloración del cabello y un masaje, por ejemplo). La “carga de trabajo” en este caso es función de lo que quieren los clientes y de cuántos clientes hay. Pero eso también varía con el tiempo. Quizás haya períodos en los que muchos clientes solo quieran adornos. Durante otros períodos (digamos, antes del Día de San Valentín), hay demanda tanto de cortes como de tintes de cabello, y sin embargo, en otras ocasiones, un masaje puede ser casi la única demanda (digamos, personas que usan todas esas tarjetas de regalo para masajes que acaban de recibir 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 un horario pico y no tiene suficientes estaciones o esteticistas calificados, la gente tendrá que esperar y algunos pueden considerar que hay demasiada gente y marcharse.

Ahora volvamos a la base de datos. Para nuestro MPP RDBMS, los “servicios” son los diferentes tipos de interacciones entre la base de datos y los ingenieros (consumo) y los sistemas que envían datos (ingesta). La ingesta consta de 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 consta de informes y consultas: algunos se ejecutan como trabajos por lotes y 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 servicio de corte versus un servicio completo en el ejemplo del salón de belleza, las solicitudes SQL podían ser muy simples o muy complejas o algo 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 nuestras intuiciones, 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), incluida la agrupación de k-medias y los árboles de clasificación y regresión (CART).

En nuestro ejemplo de salón de belleza, podríamos utilizar la agrupación de k-means y CART para analizar 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, nuestros esfuerzos de agrupación en clústeres k-means y CART revelaron que las solicitudes ETL consistían en siete clústeres (predichos por el tiempo de CPU, la E/S de subproceso más alta y el tiempo de ejecución) y las solicitudes SQL se podían agrupar en seis clústeres (según el tiempo de CPU). ).

Una vez que tuvimos nuestras agrupaciones, pudimos dar el siguiente paso, que fue caracterizar varios períodos pico. El objetivo era identificar algo equivalente a los tipos de carga de trabajo “normal”, “justo antes de San Valentín” y “justo después de San Valentín”, pero sin conocer realmente de antemano 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, utilizamos nuevamente la agrupación de k-means, esta vez para crear grupos de espacios de una hora que son similares entre sí con respecto a sus recuentos de solicitudes por grupo. Finalmente, seleccionamos algunas ranuras de una hora de cada clúster que tenía la mayor utilización general de CPU para crear cargas de trabajo de muestra.

Lo mejor de este proceso fue que estuvo impulsado por datos e información confiable basada en ML. (Este no es el caso con mi conjetura de 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 nuestro MPP RDBMS existente y varias alternativas. Puede leer el documento técnico de IT@Intel, "Minimización de los costos de gestión de datos de fabricación", para obtener una discusión completa sobre cómo creamos un punto de referencia personalizado y luego realizamos varias pruebas de concepto con proveedores para ejecutar el punto de referencia.