Usando aprendizado de máquina para caracterizar cargas de trabalho de banco de dados

Jun 27, 2023

Os bancos de dados têm nos ajudado a gerenciar nossos dados há décadas. Tal como acontece com grande parte da tecnologia com a qual trabalhamos diariamente, podemos começar a considerá-la um dado adquirido e perder a oportunidade de examinar a forma como a utilizamos – e especialmente o seu custo.

Por exemplo, a Intel armazena grande parte de seu vasto volume de dados de fabricação em um sistema de gerenciamento de banco de dados relacional (RDBMS) de processamento massivamente paralelo (MPP). Para manter os custos de gerenciamento de dados sob controle, a TI da Intel decidiu avaliar nosso RDBMS MPP atual em relação a soluções alternativas. Antes de podermos fazer isso, precisávamos entender melhor nossas cargas de trabalho de banco de dados e definir um benchmark que fosse uma boa representação dessas cargas de trabalho. Sabíamos que milhares de engenheiros de produção consultavam os dados e sabíamos quantos dados estavam sendo ingeridos no sistema. No entanto, precisávamos de mais detalhes.

“Que tipos de trabalhos constituem a carga de trabalho geral do banco de dados?”

“Como são as consultas?”

“Quantos usuários simultâneos existem para cada tipo de consulta?”

Deixe-me apresentar um exemplo para ilustrar melhor o tipo de informação de que precisávamos.

Imagine que você decidiu abrir um salão de beleza em sua cidade natal. Você deseja construir uma instalação que possa atender à demanda atual por serviços, bem como acomodar o crescimento dos negócios. Você deve estimar quantas pessoas estarão na loja no horário de pico, para saber quantas estações configurar. Você precisa decidir quais serviços irá oferecer. Quantas pessoas você pode atender depende de três fatores: 1) a velocidade com que as esteticistas trabalham; 2) quantas esteticistas trabalham; e 3) quais serviços o cliente deseja (apenas um corte, ou uma manicure, uma coloração de cabelo e uma massagem, por exemplo). A “carga de trabalho”, neste caso, é função do que os clientes desejam e de quantos clientes existem. Mas isso também varia com o tempo. Talvez haja períodos em que muitos clientes desejam apenas acabamentos. Durante outros períodos (digamos, antes do Dia dos Namorados), tanto cortes quanto coloração de cabelo são procurados, mas em outros momentos uma massagem pode ser quase a única demanda (digamos, pessoas que usam todos aqueles vales-presente de massagem que acabaram de receber no Dia dos Namorados) . Pode até ser aparentemente aleatório, sem relação com nenhum evento do calendário. Se você conseguir mais clientes em horários de pico e não tiver postos suficientes ou esteticistas qualificados, as pessoas terão que esperar, e alguns podem considerar o local muito lotado e ir embora.

Então agora vamos retornar ao banco de dados. Para nosso RDBMS MPP, os “serviços” são os diferentes tipos de interações entre o banco de dados e os engenheiros (consumo) e os sistemas que enviam dados (ingestão). A ingestão consiste em ETL (extração-transformação-carregamento) padrão, ETL de caminho crítico, carregamentos em massa e solicitações de inserção/atualização/exclusão dentro do banco de dados (grandes e pequenas). O consumo consiste em relatórios e consultas – alguns executados como trabalhos em lote, outros ad hoc.

No início da nossa caracterização da carga de trabalho, queríamos identificar os tipos de “serviços” de banco de dados que estavam sendo executados. Sabíamos que, assim como um corte versus um serviço completo no exemplo do salão de beleza, as solicitações SQL poderiam ser muito simples ou muito complexas ou algo intermediário. O que não sabíamos era como generalizar uma grande variedade dessas solicitações em algo mais gerenciável sem perder algo importante. Em vez de confiar em nossa intuição, queríamos ser metódicos. Adotamos uma abordagem inovadora para desenvolver uma compreensão completa das solicitações SQL: decidimos aplicar técnicas de aprendizado de máquina (ML), incluindo clustering k-means e árvores de classificação e regressão (CARTs).

Em nosso exemplo de salão de beleza, poderíamos usar agrupamento k-means e CART para analisar clientes e identificar grupos com semelhanças, como “apenas serviços de cabeleireiro”, “serviços de cabelo e unhas” e “apenas serviços de unhas”.

Para nosso banco de dados, nossos esforços de clustering k-means e CART revelaram que as solicitações ETL consistiam em sete clusters (previstos pelo tempo de CPU, maior E/S de thread e tempo de execução) e as solicitações SQL podiam ser agrupadas em seis clusters (com base no tempo de CPU ).