Utilizzo dell'apprendimento automatico per caratterizzare i carichi di lavoro del database

Jun 27, 2023

I database ci aiutano da decenni a gestire i nostri dati. Come gran parte della tecnologia con cui lavoriamo quotidianamente, potremmo iniziare a darle per scontate e perdere l’opportunità di esaminarne l’utilizzo, e soprattutto il loro costo.

Ad esempio, Intel archivia gran parte del suo vasto volume di dati di produzione in un sistema di gestione di database relazionali (RDBMS) con elaborazione parallela di massa (MPP). Per tenere sotto controllo i costi di gestione dei dati, Intel IT ha deciso di valutare il nostro attuale RDBMS MPP rispetto a soluzioni alternative. Prima di poterlo fare, dovevamo comprendere meglio i carichi di lavoro del nostro database e definire un benchmark che fosse una buona rappresentazione di tali carichi di lavoro. Sapevamo che migliaia di ingegneri di produzione interrogavano i dati e sapevamo quanti dati venivano inseriti nel sistema. Tuttavia, avevamo bisogno di maggiori dettagli.

"Quali tipi di lavori costituiscono il carico di lavoro complessivo del database?"

"Come sono le domande?"

"Quanti utenti simultanei ci sono per ogni tipo di query?"

Vorrei presentare un esempio per illustrare meglio il tipo di informazioni di cui avevamo bisogno.

Immagina di aver deciso di aprire un salone di bellezza nella tua città natale. Desideri costruire una struttura in grado di soddisfare la domanda odierna di servizi e di favorire la crescita aziendale. Dovresti stimare quante persone saranno presenti nel negozio nelle ore di punta, in modo da sapere quante stazioni allestire. Devi decidere quali servizi offrire. Quante persone puoi servire dipende da tre fattori: 1) la velocità con cui lavorano le estetiste; 2) quante estetiste lavorano; e 3) quali servizi desidera il cliente (solo un taglio, o una manicure, una colorazione dei capelli e un massaggio, per esempio). Il “carico di lavoro” in questo caso è una funzione di ciò che vogliono i clienti e di quanti clienti ci sono. Ma anche questo varia nel tempo. Forse ci sono periodi in cui molti clienti vogliono solo rifiniture. Durante altri periodi (ad esempio, prima di San Valentino), sono richiesti sia il taglio che la colorazione dei capelli, eppure in altri momenti un massaggio potrebbe essere quasi l'unica richiesta (ad esempio, le persone che utilizzano tutte quelle carte regalo per massaggi che hanno appena ricevuto a San Valentino) . Potrebbe anche essere apparentemente casuale, estraneo a qualsiasi evento del calendario. Se ottieni più clienti nelle ore di punta e non hai abbastanza postazioni o estetiste qualificate, le persone dovranno aspettare e alcuni potrebbero ritenerlo troppo affollato e andarsene.

Quindi ora torniamo al database. Per il nostro RDBMS MPP, i “servizi” sono i diversi tipi di interazioni tra il database e gli ingegneri (consumo) e i sistemi che inviano i dati (acquisizione). L'acquisizione consiste in ETL (estrazione-trasformazione-caricamento) standard, ETL del percorso critico, caricamenti in blocco e richieste di inserimento/aggiornamento/eliminazione all'interno del DB (sia grandi che piccole). Il consumo consiste in report e query, alcuni eseguiti come processi batch, altri ad hoc.

All'inizio della caratterizzazione del nostro carico di lavoro, volevamo identificare i tipi di "servizi" di database che venivano eseguiti. Sapevamo che, come nel caso di un servizio di rifinitura rispetto a un servizio completo nell'esempio di un salone di bellezza, le richieste SQL potevano essere molto semplici o molto complesse o una via di mezzo. Ciò che non sapevamo era come generalizzare un'ampia varietà di queste richieste in qualcosa di più gestibile senza perdere qualcosa di importante. Piuttosto che fidarci del nostro istinto, volevamo essere metodici al riguardo. Abbiamo adottato un approccio innovativo per sviluppare una piena comprensione delle richieste SQL: abbiamo deciso di applicare tecniche di Machine Learning (ML), tra cui il clustering k-means e gli alberi di classificazione e regressione (CART).

Nell'esempio del nostro salone di bellezza, potremmo utilizzare il clustering k-means e CART per analizzare i clienti e identificare gruppi con somiglianze come "solo servizi per capelli", "servizi per capelli e unghie" e "solo servizi per unghie".

Per il nostro database, i nostri sforzi di clustering k-mean e CART hanno rivelato che le richieste ETL consistevano in sette cluster (previsti in base al tempo della CPU, all'I/O del thread più elevato e al tempo di esecuzione) e le richieste SQL potevano essere raggruppate in sei cluster (in base al tempo della CPU ).