L’apprentissage automatique mettra-t-il au chômage les opérateurs de systèmes de gestion de bases de données ?

Présentation

Le système de gestion de base de données (SGBD) est la partie la plus importante de tout système d'application gourmand en données. Ils peuvent gérer de grandes quantités de données et des charges de travail complexes. Mais ils sont difficiles à gérer car ils comportent des centaines, voire des milliers de « boutons » de configuration qui contrôlent des facteurs tels que la quantité de mémoire utilisée pour la mise en cache et la fréquence d'écriture des données sur le périphérique de stockage. Les organisations embauchent souvent des experts pour les aider à affiner leurs campagnes, mais les coûts des experts sont prohibitifs pour de nombreuses entreprises.

Cet article a été co-écrit par trois invités de l'Université Carnegie Mellon : Dana Van Aken, Andy Pavlo et Geoff Gordon. Ce projet montre comment les chercheurs universitaires peuvent utiliser le programme AWS Cloud Credits for Research (https://aws.amazon.com/research-credits/) pour soutenir leurs percées scientifiques.

OtterTune est un nouvel outil développé par des étudiants et des chercheurs du groupe de base de données de l'université Carnegie Mellon (http://db.cs.cmu.edu/projects/autotune/) qui automatise la configuration du bouton du SGBD pour trouver le paramètre approprié. L’objectif est de permettre à quiconque de déployer plus facilement un SGBD, même à ceux qui n’ont aucune expertise en administration de bases de données.

OtterTune est différent des autres outils de configuration de SGBD car il exploite pleinement les connaissances acquises lors du réglage des SGBD précédemment déployés pour régler les SGBD nouvellement déployés. Cela réduit considérablement le temps et les ressources nécessaires pour régler un SGBD nouvellement déployé. À cette fin, OtterTune maintient une base de données contenant les données de réglage collectées lors des sessions de réglage précédentes. Il utilise ces données pour créer des modèles d'apprentissage automatique qui capturent des informations sur la façon dont le SGBD réagit à différentes configurations. OtterTune utilise ces modèles pour guider les utilisateurs lors de l'essai de nouvelles applications, en suggérant des paramètres qui améliorent des objectifs spécifiques, tels que la réduction de la latence ou l'augmentation du débit.

Dans cet article, nous explorons chaque composant du pipeline d'apprentissage automatique d'OtterTune et démontrons comment ils interagissent les uns avec les autres pour affiner la configuration de votre SGBD. Nous avons ensuite évalué les performances d'OtterTune sur MySQL et Postgres en comparant les performances de ses configurations optimales avec les configurations choisies par les administrateurs de bases de données (DBA) et d'autres outils de réglage automatisés.

OtterTune est un outil open source développé par des étudiants et des chercheurs du Database Group de l'Université Carnegie Mellon. Tout le code est placé sur GitHub (https://github.com/cmu-db/ottertune) et est publié sous la licence Apache 2.0.

Comment ça marche

L'image ci-dessous montre les composants et le flux de travail d'OtterTune.

Au début d'une nouvelle session de réglage, l'utilisateur indique à OtterTune pour quel objectif spécifique optimiser (comme la latence ou le débit). Le contrôleur client se connecte au SGBD cible et collecte le type d'instance Amazon EC2 et la cible actuelle.

Le contrôleur démarre alors la première période d'observation, pendant laquelle il observe le SGBD et enregistre des cibles spécifiques. Une fois la période d'observation terminée, le contrôleur collecte des métriques internes du SGBD, telles que le nombre MySQL de pages lues sur le disque et de pages écrites sur le disque. Le contrôleur renvoie à la fois des objectifs spécifiques et des métriques internes au gestionnaire de réglage.

Une fois que le gestionnaire de réglage d'OtterTune a reçu les métriques, il les stocke dans le référentiel. OtterTune utilise les résultats pour calculer la prochaine configuration que le contrôleur doit installer sur le SGBD cible. Le gestionnaire de réglage renvoie cette configuration au contrôleur et estime les améliorations attendues à travers des exécutions réelles. L'utilisateur peut décider de poursuivre la session de réglage ou d'y mettre fin.

Instructions

OtterTune maintient une liste noire de boutons pour chaque version de SGBD qu'il prend en charge. La liste noire comprend des boutons qui n'ont pas besoin d'être réglés (tels que le nom de chemin du fichier de stockage du SGBD) ou des boutons qui peuvent avoir des conséquences graves ou cachées (telles que la perte de données du SGBD). Au début de chaque session de réglage, OtterTune fournit aux utilisateurs une liste noire afin qu'ils puissent ajouter tous les autres boutons qu'ils souhaitent qu'OtterTune évite de régler.

OtterTune fait certaines hypothèses qui peuvent limiter son utilité pour certains utilisateurs. Par exemple, cela suppose que l'utilisateur dispose de droits d'administrateur, permettant au contrôleur de modifier la configuration du SGBD. Si l'utilisateur ne dispose pas de droits d'administrateur, il peut déployer une deuxième copie de la base de données sur un autre matériel pour les expériences de réglage OtterTune. Cela oblige les utilisateurs à relire les traces de charge de travail ou à transmettre les requêtes à partir d'un SGBD de niveau production. Pour une discussion complète des hypothèses et des limites, consultez notre article (http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf).

Pipeline d'apprentissage automatique

L'image ci-dessous montre comment les données sont traitées lors de leur passage dans le pipeline d'apprentissage automatique d'OtterTune. Toutes les observations sont placées dans la base de données d'OtterTune.

OtterTune transmet d'abord les résultats de l'observation au composant Workload Characterization. Ce composant identifie un petit ensemble de métriques de SGBD qui capturent avec le plus de précision les changements de performances et les caractéristiques uniques des différentes charges de travail.

Ensuite, le composant Knob Identification génère une liste de tri des boutons, répertoriant les boutons qui ont le plus grand impact sur les performances du SGBD. OtterTune transmet ensuite toutes ces informations à Automatic Tuner. Ce composant mappe la charge de travail du SGBD cible à la charge de travail la plus similaire dans le référentiel de données et réutilise les données de charge de travail pour générer une configuration plus appropriée.

Plongeons maintenant dans chaque composant du pipeline d’apprentissage automatique.

Caractérisation de la charge de travail : OtterTune utilise les métriques d'exécution internes du SGBD pour décrire les caractéristiques comportementales de la charge de travail. Ces métriques représentent avec précision la charge de travail car elles capturent de nombreux aspects du comportement d'exécution. Cependant, de nombreuses métriques sont redondantes : certaines sont les mêmes métriques enregistrées dans différentes unités, et d'autres représentent des parties indépendantes du SGBD qui sont fortement corrélées numériquement. La rationalisation des métriques redondantes est importante car elle réduit la complexité des modèles d'apprentissage automatique qui les utilisent. À cette fin, nous divisons les métriques du SGBD en clusters en fonction de modèles de corrélation. Nous sélectionnons ensuite une métrique représentative de chaque cluster, en particulier celle la plus proche du centre du cluster. Les composants suivants du pipeline d’apprentissage automatique utilisent ces métriques.

Identification des boutons : un SGBD peut avoir des centaines de boutons, mais seul un petit nombre de boutons affecte les performances du SGBD. OtterTune utilise une technique de sélection de fonctionnalités populaire appelée Lasso pour décider quels boutons affectent de manière significative les performances globales de votre système. En appliquant cette technique aux données d'une base de données, OtterTune peut identifier l'ordre d'importance des boutons du SGBD.

OtterTune doit ensuite décider du nombre de boutons à utiliser dans la configuration proposée. Utiliser trop de boutons augmente considérablement le temps d'optimisation d'OtterTune. Utiliser trop peu de boutons empêche OtterTune de trouver la configuration optimale. Pour automatiser ce processus, OtterTune utilise une approche incrémentielle. Il augmente progressivement le nombre de boutons utilisés dans une session de réglage. Cette approche permet à OtterTune d'explorer et d'optimiser les configurations pour un petit ensemble de boutons les plus importants, puis d'élargir la portée pour prendre en compte des boutons supplémentaires.

Tuner automatique : le composant de réglage automatisé détermine quelle configuration OtterTune doit recommander en effectuant une analyse en deux étapes après chaque période d'observation.

Tout d'abord, le système identifie la charge de travail d'une session de réglage précédente qui représente le mieux la charge de travail du SGBD cible à l'aide de données de performances par rapport aux métriques identifiées dans le composant de caractérisation de la charge de travail. Il compare les métriques de la session aux métriques des charges de travail précédentes pour voir lesquelles réagissent de la même manière aux différents paramètres des boutons.

Ensuite, OtterTune sélectionne une autre configuration de bouton pour l'essayer. Il adapte les modèles statistiques aux données collectées, ainsi qu'aux données des charges de travail les plus similaires du référentiel. Ce modèle permet à OtterTune de prédire les performances du SGBD en utilisant toutes les configurations possibles. OtterTune optimise la configuration suivante pour trouver un équilibre entre l'exploration (collecter des informations pour améliorer le modèle) et l'exploitation (fonctionner au mieux sur une métrique spécifique).

Réalisé

OtterTune est écrit en Python.

En ce qui concerne la caractérisation de la charge de travail et l'identification des boutons, les performances d'exécution ne sont pas le principal problème dont il faut se soucier, nous avons donc utilisé scikit-learn pour implémenter l'algorithme d'apprentissage automatique correspondant. Ces algorithmes fonctionnent en arrière-plan et intégreront les nouvelles données dès qu'elles seront disponibles dans la base de données d'OtterTune.

Quant à l’Automatic Tuner, l’algorithme d’apprentissage automatique est sur le chemin critique. Ils s'exécutent après chaque période d'observation, intégrant de nouvelles données afin qu'OtterTune puisse sélectionner une configuration de bouton à essayer ensuite. Les performances étant un facteur à prendre en compte, nous avons implémenté ces algorithmes à l'aide de TensorFlow.

Pour collecter des données sur le matériel du SGBD, les configurations des boutons et les mesures de performances d'exécution, nous avons intégré le contrôleur d'OtterTune au cadre d'analyse comparative OLTP-Bench.

Évaluation

Pour évaluer, nous avons comparé la meilleure configuration sélectionnée par OtterTune avec les configurations suivantes pour les performances MySQL et Postgres :

• Par défaut : configuration fournie par le SGBD
• Script de réglage : configuration générée par l'outil de conseil de réglage open source
• DBA : configuration générée par l'administrateur de base de données
• RDS : Configuration personnalisée pour SGBD, gérée par Amazon RD, déployée sur le même type d'instance EC2.

Nous avons mené toutes les expériences sur les instances Spot Amazon EC2. Nous avons mené chaque essai sur deux instances : une pour le contrôleur d'OtterTune et une autre pour le système SGBD cible déployé. Nous avons utilisé respectivement les types d'instance m4.large et m3.xlarge. Nous avons déployé le gestionnaire de réglage et la base de données d'OtterTune sur un serveur local équipé de 20 cœurs et de 128 Go de mémoire.

Nous avons utilisé la charge de travail TPC-C, qui est la norme industrielle pour évaluer les performances des systèmes de traitement des transactions en ligne (OLTP).

Nous avons mesuré la latence et le débit par rapport à chaque base de données que nous avons utilisée dans nos expériences : MySQL et Postgres. Les figures suivantes montrent les résultats. Le premier graphique montre le montant de la latence du 99e percentile, qui représente le temps « dans le pire des cas » nécessaire à l’achèvement d’une transaction. Le deuxième graphique montre les résultats du débit, mesuré comme le nombre moyen de transactions terminées par seconde.

Résultats MySQL :

En comparant la configuration optimale générée par OtterTune avec la configuration générée par le script de réglage et RDS, vous constaterez que si vous utilisez la configuration OtterTune, la latence de MySQL est réduite d'environ 60 % et le débit est augmenté de 35 %. OtterTune produit également des configurations avec des résultats aussi bons que ceux choisis par l'administrateur de la base de données.

Quelques boutons MySQL ont un impact significatif sur les performances des charges de travail TPC-C. Les configurations générées par OtterTune et l'administrateur de la base de données fournissent de bons paramètres pour chacun de ces boutons. RDS a fonctionné un peu moins bien en raison de paramètres sous-optimaux pour un bouton. La configuration du script de réglage a été la moins performante puisqu'un seul bouton a été modifié.

Résultats pour Postgres :

En termes de latence, OtterTune, les outils de réglage, la gestion de bases de données et les configurations générées par RDS affichent tous des améliorations similaires par rapport aux paramètres par défaut de Postgres. Nous pouvons probablement attribuer cela à la surcharge requise pour l'aller-retour entre le client OLTP-Bench et le SGBD sur le réseau. En ce qui concerne le débit, si vous utilisez la configuration recommandée par OtterTune, les performances de Postgres sont environ 12 % supérieures à la configuration sélectionnée par l'administrateur de la base de données et le script de réglage, et environ 32 % supérieures à celles de RDS.

Semblable à MySQL, seuls quelques boutons ont un impact significatif sur les performances de Postgres. OtterTune, les administrateurs de bases de données, les scripts de réglage et les configurations générées par RDS modifient tous ces boutons, et la plupart fournissent de très bons paramètres.

Conclusion

OtterTune automatise le processus de recherche des bons paramètres pour les boutons de configuration d'un SGBD. Pour régler un SGBD nouvellement déployé, il réutilise les données de formation collectées lors des sessions de réglage précédentes. Étant donné qu'OtterTune ne nécessite pas la génération d'ensembles de données initiaux pour la formation des modèles d'apprentissage automatique, le temps de réglage est considérablement réduit.

Quelle est la prochaine étape ? Pour répondre à la popularité croissante des déploiements DBaaS qui n'ont pas d'accès à distance au système hôte du SGBD, OtterTune sera bientôt en mesure de détecter automatiquement les capacités matérielles du DMBS cible sans nécessiter d'accès à distance.

Pour plus de détails sur OtterTune, consultez notre article ou le code sur GitHub. Veuillez prêter attention à ce site Web (http://ottertune.cs.cmu.edu/), nous lancerons bientôt OtterTune, un service de réglage en ligne.
À propos de l'auteur :

Dana Van Aken est doctorante en informatique à l'Université Carnegie Mellon, encadrée par le Dr Andrew Pavlo.

Andy Pavlo est professeur adjoint de science des bases de données au département d'informatique de l'université Carnegie Mellon.

Geoff Gordon est professeur agrégé et directeur associé de l'éducation au département d'apprentissage automatique de l'Université Carnegie Mellon.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!