Ce document du framework d'architecture de Google Cloud fournit des recommandations pour vous aider à optimiser les performances de vos bases de données dans Google Cloud.
Cloud SQL
Les recommandations suivantes vous permettent d'optimiser les performances de vos instances Cloud SQL exécutant des bases de données SQL Server, MySQL et PostgreSQL.
- Pour les bases de données SQL Server, Google vous recommande de modifier certains paramètres et de conserver les valeurs par défaut de certains paramètres.
- Lorsque vous choisissez le type de stockage pour les bases de données MySQL ou PostgreSQL, tenez compte du compromis en termes de coûts et de performances entre le stockage SSD et HDD.
- Pour identifier et analyser les problèmes de performances des bases de données PostgreSQL, utilisez le tableau de bord Cloud SQL Insights.
- Pour diagnostiquer les mauvaises performances lors de l'exécution de requêtes SQL, utilisez l'instruction
EXPLAIN.
Pour en savoir plus, consultez la documentation suivante :
- Optimiser les performances : SQL Server
- Optimiser les performances : MySQL
- Optimiser les performances : PostgreSQL
Bigtable
Cette section fournit des recommandations pour vous aider à optimiser les performances de vos instances Bigtable.
Planifier la capacité en fonction des exigences de performances
Vous pouvez utiliser Bigtable dans un large éventail d'applications, avec un objectif d'optimisation différent pour chacune d'entre elles. Par exemple, pour les tâches de traitement de données par lots, le débit peut être plus important que la latence. Pour un service en ligne qui traite les requêtes des utilisateurs, vous devrez peut-être donner la priorité à une latence plus faible. Lorsque vous planifiez la capacité de vos clusters Bigtable, tenez compte des compromis entre débit et latence. Pour en savoir plus, consultez la section Planifier la capacité Bigtable.
Suivre les bonnes pratiques liées à la conception de schémas
Vos tables peuvent contenir jusqu'à plusieurs milliards de lignes et des milliers de colonnes, ce qui vous permet de stocker des pétaoctets de données. Lorsque vous concevez le schéma de vos tables Bigtable, tenez compte des bonnes pratiques liées à la conception de schémas.
Surveiller les performances et effectuer des ajustements
Surveillez l'utilisation de processeur et de disque de vos instances, analysez les performances de chaque cluster et examinez les recommandations de dimensionnement affichées dans les graphiques de surveillance.
Spanner
Cette section fournit des recommandations pour vous aider à optimiser les performances de vos instances Spanner.
Choisir une clé primaire qui empêche un hotspot
Un hotspot est un serveur unique qui est contraint de traiter de nombreuses requêtes. Lorsque vous choisissez la clé primaire de votre base de données, suivez les bonnes pratiques liées à la conception de schémas pour éviter ce problème.
Suivre les bonnes pratiques de codage SQL
Le compilateur SQL de Spanner convertit chaque instruction SQL déclarative que vous écrivez en plan d'exécution de requêtes impératif. Spanner utilise le plan d'exécution pour exécuter l'instruction SQL. Lorsque vous créez des instructions SQL, suivez les bonnes pratiques SQL pour vous assurer que Spanner utilise des plans d'exécution offrant des performances optimales.
Utiliser les options de requête pour gérer l'optimiseur de requête SQL
Spanner utilise un optimiseur de requête SQL pour transformer les instructions SQL en plans d'exécution de requêtes efficaces. Le plan d'exécution de requêtes produit par l'optimiseur peut varier légèrement lorsque l'optimiseur lui-même évolue ou lorsque les statistiques de base de données sont mises à jour. Vous pouvez minimiser le risque de régression des performances lorsque l'optimiseur de requêtes ou les statistiques de la base de données changent en utilisant les options de requête.
Visualiser et ajuster la structure des plans d'exécution de requêtes
Pour analyser les problèmes de performances des requêtes, vous pouvez visualiser et ajuster la structure des plans d'exécution de requêtes en utilisant le visualiseur du plan de requête.
Utiliser des API d'opérations pour gérer les opérations de longue durée
Pour certains appels de méthode, Spanner crée des opérations de longue durée qui peuvent prendre un temps considérable. Par exemple, lorsque vous restaurez une base de données, Spanner crée une opération de longue durée pour suivre l'avancement de la restauration. Pour vous aider à surveiller et à gérer les opérations de longue durée, Spanner fournit des API d'opérations. Pour en savoir plus, consultez la page Gérer les opérations de longue durée.
Suivre les bonnes pratiques pour le chargement groupé
Spanner propose plusieurs options pour le chargement groupé de grandes quantités de données. Les performances d'une opération de chargement groupé dépendent de facteurs tels que le partitionnement, le nombre de requêtes d'écriture et la taille de chaque requête. Pour charger efficacement de grandes quantités de données, suivez les bonnes pratiques de chargement groupé.
Surveiller et contrôler l'utilisation du processeur
L'utilisation de processeur de votre instance Spanner peut affecter la latence des requêtes. Un serveur backend surchargé peut entraîner une latence plus élevée pour les requêtes. Spanner fournit des métriques d'utilisation du processeur pour vous aider à identifer la cause de l'utilisation élevée du processeur. Pour les applications sensibles aux performances, vous devrez peut-être réduire l'utilisation du processeur en augmentant la capacité de calcul.
Analyser et résoudre les problèmes de latence
Lorsqu'un client effectue un appel de procédure à distance vers Spanner, la requête d'API est d'abord préparée par les bibliothèques clientes. La requête passe ensuite par Google Front End et par l'interface de l'API Cloud Spanner avant d'atteindre la base de données Spanner. Pour analyser et résoudre les problèmes de latence, vous devez mesurer et analyser la latence pour chaque segment du chemin traversé par la requête d'API. Pour plus d'informations, consultez le guide de latence de bout en bout Spanner.
Lancer les applications une fois que la base de données est à l'état chaud
Au fur et à mesure que votre base de données Spanner s'agrandit, elle divise l'espace clé de vos données en divisions. Chaque division est une plage de lignes contenant un sous-ensemble de votre table. Pour équilibrer la charge globale de la base de données, Spanner déplace les divisions de manière indépendante et les attribue à différents serveurs. Lorsque les divisions sont réparties sur plusieurs serveurs, la base de données est considérée comme à l'état chaud. Une base de données à l'état chaud peut maximiser le parallélisme et offrir des performances améliorées. Avant de lancer vos applications, nous vous recommandons de préchauffer votre base de données avec des charges de données de test.
Étapes suivantes
Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources de calcul, de stockage, de mise en réseau et d'analyse :
- Optimiser les performances de calcul.
- Optimiser les performances de stockage.
- Optimiser les performances du réseau.
- Optimiser les performances des analyses.