Utiliser l'apprentissage automatique pour caractériser les charges de travail des bases de données

Jun 27, 2023

Les bases de données nous aident à gérer nos données depuis des décennies. Comme c’est le cas pour la plupart des technologies avec lesquelles nous travaillons quotidiennement, nous risquons de commencer à les prendre pour acquises et de rater l’occasion d’examiner notre utilisation de celles-ci, et en particulier leur coût.

Par exemple, Intel stocke une grande partie de son vaste volume de données de fabrication dans un système de gestion de base de données relationnelle (SGBDR) à traitement massivement parallèle (MPP). Pour garder les coûts de gestion des données sous contrôle, Intel IT a décidé d'évaluer notre SGBDR MPP actuel par rapport à des solutions alternatives. Avant de pouvoir faire cela, nous devions mieux comprendre nos charges de travail de bases de données et définir une référence qui soit une bonne représentation de ces charges de travail. Nous savions que des milliers d'ingénieurs de fabrication interrogeaient les données et nous savions quelle quantité de données était ingérée dans le système. Cependant, nous avions besoin de plus de détails.

« Quels types de tâches constituent la charge de travail globale de la base de données ? »

« À quoi ressemblent les requêtes ?

"Combien d'utilisateurs simultanés y a-t-il pour chaque type de requête ?"

Permettez-moi de présenter un exemple pour mieux illustrer le type d’informations dont nous avions besoin.

Imaginez que vous ayez décidé d'ouvrir un salon de beauté dans votre ville natale. Vous souhaitez construire une installation capable de répondre à la demande actuelle de services ainsi que de répondre à la croissance de votre entreprise. Vous devez estimer le nombre de personnes qui seront dans le magasin aux heures de pointe, afin de savoir combien de stations installer. Vous devez décider quels services vous offrirez. Le nombre de personnes que vous pouvez servir dépend de trois facteurs : 1) la rapidité avec laquelle les esthéticiennes travaillent ; 2) combien d'esthéticiennes travaillent ; et 3) quels services le client souhaite (juste une coupe, ou une manucure, une coloration et un massage, par exemple). La « charge de travail » dans ce cas est fonction de ce que veulent les clients et de leur nombre. Mais cela varie aussi dans le temps. Il y a peut-être des périodes où de nombreux clients veulent simplement des garnitures. À d'autres périodes (par exemple, avant la Saint-Valentin), les coupes et la coloration des cheveux sont très demandées, et pourtant, à d'autres moments, un massage peut être presque la seule demande (par exemple, les personnes utilisant toutes ces cartes-cadeaux de massage qu'elles viennent de recevoir le jour de la Saint-Valentin). . Cela peut même être apparemment aléatoire, sans rapport avec un événement du calendrier. Si vous avez plus de clients aux heures de pointe et que vous n'avez pas assez de stations ou d'esthéticiennes qualifiées, les gens devront attendre, et certains pourraient trouver le lieu trop fréquenté et s'en aller.

Revenons maintenant à la base de données. Pour notre RDBMS MPP, les « services » sont les différents types d'interactions entre la base de données et les ingénieurs (consommation) et les systèmes qui envoient des données (ingestion). L'ingestion comprend l'extraction-transformation-chargement (ETL) standard, l'ETL du chemin critique, les chargements en bloc et les requêtes d'insertion/mise à jour/suppression au sein de la base de données (grandes et petites). La consommation se compose de rapports et de requêtes : certains s'exécutent sous forme de tâches par lots, d'autres de manière ponctuelle.

Au début de notre caractérisation de la charge de travail, nous voulions identifier les types de « services » de bases de données qui étaient exécutés. Nous savions que, comme pour un service complet par rapport à un service complet dans l'exemple d'un salon de beauté, les requêtes SQL pouvaient être très simples ou très complexes ou quelque part entre les deux. Ce que nous ne savions pas, c'était comment généraliser une grande variété de ces demandes en quelque chose de plus gérable sans manquer quelque chose d'important. Plutôt que de nous fier à notre intuition, nous avons voulu être méthodiques. Nous avons adopté une nouvelle approche pour développer une compréhension complète des requêtes SQL : nous avons décidé d'appliquer des techniques d'apprentissage automatique (ML), notamment le clustering k-means et les arbres de classification et de régression (CART).

Dans notre exemple de salon de beauté, nous pourrions utiliser le clustering k-means et CART pour analyser les clients et identifier les groupes présentant des similitudes telles que « services de coiffure uniquement », « services de coiffure et d'ongles » et « services d'ongles uniquement ».

Pour notre base de données, nos efforts de clustering k-means et CART ont révélé que les requêtes ETL se composaient de sept clusters (prédits par le temps CPU, les E/S de thread les plus élevées et le temps d'exécution) et que les requêtes SQL pouvaient être regroupées en six clusters (en fonction du temps CPU). ).