Cette page fournit une stratégie pour planifier et exécuter une démonstration de faisabilité avec Spanner. Il fournit des références et des insights détaillés sur les aspects essentiels d'une démonstration de faisabilité, tels que la configuration de l'instance, la conception du schéma, le chargement des données et l'évaluation des performances. Il met en évidence les étapes essentielles pour évaluer les capacités de Spanner et vous aide à identifier les risques et avantages potentiels liés à l'adoption de Spanner.
En plus de valider les capacités techniques de Spanner, un POC sert deux objectifs :
- Pour vous aider à comprendre les avantages que Spanner offre pour votre cas d'utilisation
- Pour vous aider à identifier les risques associés à l'adoption de Spanner
Une preuve de concept Spanner englobe diverses facettes d'évaluation, chacune étant personnalisée pour répondre à vos objectifs commerciaux et techniques spécifiques, comme illustré dans le diagramme suivant.
Les consignes de ce document vous aident à évaluer chacun de ces domaines.
La section Performances et évolutivité vous aide à comprendre comment Spanner gère les charges de travail spécifiques, les exigences de latence et l'impact des différentes configurations d'instance. Ces tests peuvent démontrer la capacité de Spanner à évoluer de manière fluide.
Les fonctionnalités de surveillance vous aident à évaluer si Spanner fournit les insights nécessaires pour des opérations de base de données efficaces. Voici ce que cette évaluation inclut :
- Options pour analyser les plans d'exécution de requêtes
- Utilisation des ressources système
- Options de configuration des alertes
Une preuve de concept peut révéler des lacunes à combler pour optimiser pleinement l'efficacité opérationnelle.
La sécurité et la conformité sont essentielles pour déterminer si Spanner convient à votre organisation. Cela inclut des évaluations visant à garantir que Spanner peut atténuer les risques de sécurité tout en offrant des avantages de conformité solides, tels que les suivants :
- Options de chiffrement, telles que CMEK ou EKM pour les données en transit et au repos
- Posture de contrôle des accès de moindre privilège
- Journaux d'audit
- Respect des exigences réglementaires
Les fonctionnalités de sauvegarde et de reprise après sinistre sont essentielles pour assurer la résilience opérationnelle et des données. Un POC peut valider les fonctionnalités de reprise après sinistre de Spanner, telles que la récupération à un moment précis et la disponibilité.
La faisabilité de la migration consiste à comprendre la complexité du passage de votre solution de base de données actuelle à Spanner. L'évaluation de la compatibilité des schémas, des outils de migration et des modifications apportées aux applications vous aide à quantifier les investissements requis, et à déterminer les risques et les avantages de l'adoption de Spanner.
Lors de votre évaluation, vous pouvez explorer l'ensemble des fonctionnalités de Spanner pour vous assurer qu'il répond aux exigences fonctionnelles de votre application. Cela peut inclure le test de sa cohérence globale, de ses capacités de requête SQL ou de son intégration à d'autres services Google Cloud.
Les évaluations peuvent mettre en évidence les points forts uniques de Spanner, comme la cohérence entre les régions, mais aussi les risques potentiels, comme les efforts d'intégration avec l'architecture d'application existante.
Cycle de vie des activités de validation
Ce POC vous guide tout au long des étapes suivantes. Suivez les recommandations de ce document pour configurer et évaluer Spanner en fonction de votre cas d'utilisation spécifique.
Planifier votre POC
Pour qu'un POC soit efficace, il faut définir des objectifs clairs et mesurables qui correspondent aux priorités techniques et commerciales. Évitez les objectifs vagues tels que explorer le potentiel de Spanner, car ils conduisent souvent à des efforts non ciblés et à des résultats ambigus. Au lieu de cela, associez vos objectifs de POC à des cibles concrètes, comme atteindre une disponibilité de 99, 999 %, réduire les temps d'arrêt ou évoluer pour gérer une augmentation de 200 % du débit tout en maintenant les latences de transaction en dessous de 20 ms.
L'architecture unique de Spanner est idéale pour les charges de travail nécessitant une évolutivité massive. Il est donc judicieux de commencer par évaluer l'évolutivité pour votre cas d'utilisation. Les scénarios de test doivent inclure :
- Gérer les charges opérationnelles types
- Gérer les pics de trafic
- Réduire efficacement la taille
Ces tests vous aident à comprendre les performances de Spanner dans différentes conditions et à déterminer s'il répond à vos exigences techniques en termes d'évolutivité. Des objectifs spécifiques et concrets permettent non seulement de structurer le POC, mais aussi de créer une base solide pour évaluer la réussite.
Définir une grille d'évaluation quantifiée
Une grille d'évaluation composée de métriques claires et mesurables, ainsi que de critères de réussite distincts, est essentielle pour déterminer si le POC a atteint ses objectifs. Par exemple, au lieu de tester uniquement les performances, vous devez également spécifier des objectifs tels que :
- Diffuser des RPS (requêtes par seconde) spécifiques au niveau de la production
- Maintenir une latence inférieure à 20 ms sous des charges maximales prédéfinies
- Gérer les pics de trafic clairement définis sans dégradation des performances
Des critères bien définis vous aident à évaluer Spanner de manière objective pour votre charge de travail et à obtenir des insights exploitables pour les prochaines étapes. Soyez précis et définissez des cibles de centiles pour la latence des opérations de lecture et d'écriture (par exemple, p50 et p95). Une définition claire des seuils de latence acceptables vous aide à concevoir des tests de performances Spanner qui correspondent à vos besoins commerciaux.
Voici un exemple de grille d'évaluation :
| Attribut d'évaluation | Critères de réussite |
| Disponibilité | 99,999 % |
| Sécurité | CMEK avec EKM requis |
| Garantie de l'objectif de point de récupération (RPO) en cas d'indisponibilité régionale | 0 |
| Limite de latence pour les transactions les plus critiques | p50 inférieur à 20 ms |
| Latence pour nos requêtes les plus importantes destinées aux utilisateurs | p50 inférieur à 100 ms |
| Évolutivité | Démontrez qu'il est possible de passer de 10 000 à 100 000 transactions par seconde avec une latence p50 inférieure à 20 ms en une heure. |
Définir le champ d'application de vos cas d'évaluation
Une démonstration de faisabilité ne doit pas nécessiter une migration à grande échelle. Concentrez-vous plutôt sur le test de charges de travail représentatives ou de composants critiques de votre système. Par exemple, identifiez les requêtes clés, les formes de transactions critiques ou les workflows spécifiques basés sur les données qui sont essentiels à vos opérations. Limitez le champ d'application pour réduire la complexité tout en veillant à ce que les résultats soient pertinents et significatifs. Cette approche permet d'évaluer les capacités de Spanner de manière gérable, sans être submergé par les complexités d'une migration complète du système.
Choisir une configuration d'instance Spanner
Lorsque vous créez une instance Spanner à des fins d'évaluation, choisissez une configuration d'instance qui répond aux exigences de votre entreprise en termes d'emplacement géographiqueet de contrat de niveau de service pour la disponibilité des services. Spanner propose différentes configurations, y compris des configurations régionales, multirégionales et birégionales. Chaque configuration est conçue pour répondre à des exigences différentes en termes de latence, de disponibilité et de redondance.
- Les configurations à une seule région stockent les données dans une seule région Google Cloud, ce qui permet de réduire la latence dans cette région et de limiter les coûts. Ces topologies sont idéales pour les charges de travail qui nécessitent une redondance zonale intrarégionale offrant une disponibilité de 99,99 %.
- Les configurations birégionales répliquent les données dans deux régions d'un même pays, avec une réplique témoin dans chaque région pour les basculements. Cette configuration offre une disponibilité (99,999 %) et une tolérance aux pannes supérieures à celles d'une configuration à une seule région. Ces topologies conviennent aux charges de travail soumises à des exigences strictes en matière de conformité (comme la résidence des données) ou de proximité géographique.
- Les configurations multirégionales répliquent les données dans plusieurs régions, ce qui assure une très haute disponibilité et une résilience face aux pannes régionales. Ces topologies sont idéales pour les applications nécessitant une géoredondance avec une disponibilité allant jusqu'à 99,999 %.
Considérations sur la latence dans les instances multirégionales
Dans les configurations birégionales et multirégionales, la distribution géographique des répliques Spanner peut avoir une incidence sur la latence. La latence d'écriture dépend de la proximité de la région principale, qui coordonne les transactions de lecture/écriture, et des autres régions, qui confirment chaque opération d'écriture. Placer les ressources de calcul de votre application à proximité de la région principale réduit les délais aller-retour et minimise la latence.
Vous pouvez modifier la région principale d'une base de données pour l'adapter aux besoins de votre application. Pour les opérations en lecture seule, Spanner peut diffuser des lectures non actualisées à partir de l'instance répliquée la plus proche, ce qui réduit la latence. En revanche, les lectures fortes peuvent impliquer la région leader, ce qui peut augmenter la latence des opérations. Pour optimiser la latence dans les configurations multirégionales, choisissez stratégiquement la région principale, colocalisez les ressources de calcul de vos services avec la région principale et profitez des lectures obsolètes pour les charges de travail lourdes en lecture.
Configurations qui répondent aux exigences de votre application
Lorsque vous sélectionnez une configuration d'instance pour votre application, tenez compte de facteurs tels que la disponibilité, la latence et les exigences de résidence des données. Par exemple, si votre application nécessite des réponses à faible latence pour les utilisateurs d'une zone géographique spécifique, une instance régionale peut suffire. Toutefois, pour les applications qui exigent une disponibilité plus élevée ou qui desservent des utilisateurs répartis dans le monde entier, les configurations multirégionales sont plus appropriées.
Commencez par une configuration qui correspond étroitement aux exigences de production de votre application pour évaluer les performances. N'oubliez pas que la latence et les coûts varient selon les configurations. Adaptez donc votre environnement de POC aux besoins de votre cas d'utilisation. Pour les déploiements multirégionaux, simulez la distribution géographique des services et testez la latence pour vous assurer que la configuration correspond à vos exigences de production. Pour en savoir plus, consultez Conseils sur le placement des leaders multirégionaux Spanner.
Taille de Spanner
Provisionnez la capacité de calcul initiale de votre instance Spanner pour vous assurer qu'elle peut gérer efficacement votre charge de travail d'évaluation pendant le POC. La taille initiale de l'instance doit correspondre à la charge de travail attendue, en tenant compte du nombre de requêtes de lecture et d'écriture par seconde (RPS), de la complexité des requêtes et des niveaux de concurrence.
En commençant par une hypothèse raisonnable, vous pouvez établir une référence et augmenter progressivement votre budget en fonction des performances observées. Vous pouvez utiliser les conseils de dimensionnement des benchmarks de référence de Spanner pour établir une configuration d'instance de référence.
Le dimensionnement lors d'un POC doit être itératif. Commencez par une configuration initiale, puis surveillez les métriques clés telles que la latence et l'utilisation du processeur, et ajustez la capacité de calcul attribuée si nécessaire. Vous pouvez ainsi valider les capacités d'évolutivité et de performances de Spanner tout en reproduisant des conditions similaires à celles de votre environnement de production.
Les modèles de charge de travail typiques, tels que le trafic constant par rapport à la demande fluctuante, doivent influencer votre approche de dimensionnement. Lorsque vous activez l'autoscaling, Spanner provisionne dynamiquement sa capacité de ressources de calcul pour correspondre à l'intensité de la charge de travail.
Conception de schémas
La conception du schéma est un aspect essentiel d'un POC Spanner, car la façon dont vous organisez vos données peut avoir un impact direct sur les performances et l'évolutivité.
Un schéma bien conçu est essentiel pour démontrer les capacités de Spanner dans un POC. Les tests de charge révèlent souvent des goulots d'étranglement ou des inefficacités potentielles, ce qui permet d'effectuer des améliorations itératives pour créer un schéma optimal.
Concevoir pour l'évolutivité
Lorsque vous créez un schéma de base de données pour Spanner, il est essentiel de tenir compte de son architecture distribuée. Voici quelques points clés à prendre en compte et optimisations à effectuer :
- Clés primaires : choisissez des clés primaires qui répartissent les données de manière uniforme dans l'espace clé, en évitant les clés à croissance monotone telles que les codes temporels, qui peuvent provoquer des points d'accès sur les divisions.
- Index : concevez des index pour optimiser les performances des requêtes tout en tenant compte de leur impact sur les performances d'écriture et les coûts de stockage. Un trop grand nombre d'index ou des index mal planifiés peuvent entraîner des frais généraux inutiles.
- Entrelacement des tables : utilisez l'entrelacement des tables pour optimiser les modèles d'accès aux données associées. Cela peut réduire la communication entre les processus et améliorer l'efficacité des requêtes.
Consultez les bonnes pratiques de conception de schémas Spanner pour éviter les pièges courants et concevoir un schéma qui favorise les performances et l'évolutivité.
Vous pouvez créer un schéma brouillon dans la console Google Cloud , comme illustré dans l'image suivante.
Migration de schéma avec l'outil de migration Spanner
L'outil de migration Spanner (SMT) peut simplifier la création de schémas lors de la migration depuis des bases de données relationnelles, y compris MySQL ou PostgreSQL. SMT automatise la génération de schémas et inclut des optimisations de base, comme la suggestion d'index et d'ajustements de schémas. Bien que SMT constitue un bon point de départ, des ajustements manuels sont souvent nécessaires pour aligner le schéma sur vos cas d'utilisation ou modèles de charge de travail spécifiques.
Utiliser un processus de conception de schéma itératif
Bien qu'un schéma initial constitue un point de départ, il est peu probable qu'il soit parfait. La création d'un schéma pour un POC n'est pas une tâche ponctuelle, mais un processus itératif qui évolue à mesure que vous obtenez des insights à partir de vos tests. Un schéma robuste est essentiel pour les performances des applications. Pour l'obtenir, il faut une conception initiale bien pensée, l'utilisation d'outils comme SMT et un affinement itératif basé sur les résultats des tests de charge. En suivant ce processus, vous pouvez vous assurer que votre schéma répond efficacement aux exigences de votre application. Vous découvrirez également comment tirer le meilleur parti des fonctionnalités de Spanner.
Chargement des données…
Pour réussir un POC Spanner, vous devez charger des données représentatives dans la base de données afin de valider la conception du schéma et de simuler les workflows d'application. Plusieurs outils recommandés peuvent simplifier ce processus. Pour charger vos propres données, Spanner propose les options suivantes :
- L'ETL (extraction, transformation et chargement) inversé de BigQuery vers Spanner est un mécanisme de chargement de données intégré et facile à utiliser qui vous permet d'utiliser des transformations basées sur SQL pour charger des données dans Spanner. Cette méthode est idéale pour un large éventail de formats de données, y compris les données semi-structurées comme JSON.
- Pour les bases de données relationnelles telles que MySQL et PostgreSQL, l'outil de migration Spanner (SMT) automatise la création de schémas, le mappage des types de données et le chargement de données groupées.
- Pour les formats de fichier plat, Google fournit des modèles Dataflow pour CSV vers Spanner et Avro vers Spanner afin de créer des définitions de schéma manuelles pour le chargement groupé de données. Pour les bases de données compatibles avec JDBC, Google fournit le modèle Dataflow JDBC vers Spanner.
Pour en savoir plus sur ces options, consultez Utiliser vos propres données.
Si aucun exemple de données n'est disponible, vous pouvez utiliser des outils de génération de données synthétiques tels que JMeter de Machmeter et QuickPerf pour vous aider à créer des ensembles de données adaptés à votre schéma et à votre cas d'utilisation. Pour en savoir plus, consultez Générer des exemples de données.
Utiliser vos propres données
Si vous disposez d'exemples de données que vous souhaitez utiliser pour le POC, plusieurs options s'offrent à vous pour les charger dans Spanner.
| Source | Outil | Création de schémas | Transformations | Taille des données |
| MySQL | SMT | automatique | Conversion du type de données uniquement | modestement |
| PostgreSQL | SMT | automatique | Conversion du type de données uniquement | modestement |
| Tout JDBC | JDBC vers Spanner | manuel | Conversion du type de données uniquement | grand |
| CSV | CSV vers Spanner | manuel | Conversion du type de données uniquement | grand |
| Opérations ETL inversées BigQuery | manuel | Transformations complexes acceptées | grand | |
| Avro | Avro vers Spanner | manuel | Conversion du type de données uniquement | grand |
| Opérations ETL inversées BigQuery | manuel | Transformations complexes acceptées | grand | |
| JSON | Opérations ETL inversées BigQuery | manuel | Transformations complexes acceptées | grand |
ETL inversé BigQuery vers Spanner
BigQuery Reverse ETL vers Spanner vous permet d'ingérer rapidement un large éventail de sources de données et de les transformer en tables BigQuery à l'aide de SQL. Vous pouvez ensuite exporter les données de la table BigQuery vers une table Spanner. Il est particulièrement utile pour les données semi-structurées, telles que JSON, qui proviennent souvent d'exportations de sources de données NoSQL. Bien que BigQuery dispose d'une détection automatique de schéma, la création de schéma Spanner est manuelle. Vous devez définir le schéma avant de charger les données.
Outil de migration Spanner
Pour accélérer votre POC, vous pouvez utiliser l'outil de migration Spanner (SMT) pour migrer les données des sources MySQL et PostgreSQL vers Spanner. SMT automatise le processus de création de schéma en mappant les types de données de la base de données source sur leurs types équivalents dans Spanner. Il fournit également des recommandations d'optimisation de schéma spécifiques à Spanner. Cela la rend particulièrement utile pour les migrations simples où la conversion automatique du schéma est suffisante.
L'outil SMT fournit une interface utilisateur qui vous guide tout au long du processus de migration. Au cours de ce processus, vous sélectionnez la base de données source et examinez les recommandations et les options de conception du schéma.
Modèles Dataflow
Dataflow est un service entièrement géré conçu pour le traitement de données évolutif, ce qui en fait un choix approprié pour le chargement de grandes quantités de données.
Google fournit les modèles Open Source suivants pour les modèles de chargement courants :
- CSV vers Spanner charge les données des fichiers CSV stockés dans Cloud Storage dans Spanner.
- Avro vers Spanner charge les fichiers de données Avro existants depuis Cloud Storage.
- JDBC vers Spanner charge les données à partir de bases de données compatibles avec JDBC.
Chacun de ces modèles nécessite que vous créiez manuellement le schéma Spanner avant de commencer le chargement des données.
Dataflow effectue automatiquement un scaling horizontal pour s'adapter aux ensembles de données de n'importe quelle taille, ce qui garantit une ingestion de données hautes performances dans Spanner, même pour les ensembles de données de l'ordre du téraoctet. Cette évolutivité s'accompagne de quelques compromis :
- Les pipelines Dataflow nécessitent une configuration manuelle pour définir le schéma, le mappage des données et les paramètres d'exécution afin d'optimiser l'exécution.
- Dataflow offre la flexibilité et la puissance nécessaires pour les migrations de données à grande échelle, mais sa configuration et sa gestion peuvent être plus complexes que celles d'autres outils.
Générer des exemples de données
Si vous ne disposez pas d'exemples de données, mais que vous avez un cas d'utilisation spécifique en tête, vous pouvez modéliser le schéma en fonction de vos besoins et utiliser des outils pour générer des ensembles de données représentatifs. Ces outils vous permettent d'alimenter Spanner avec des données pertinentes pour valider la conception de votre schéma et les workflows de vos applications.
JMeter de Machmeter
JMeter de Machmeter fournit des exemples qui utilisent JMeter pour générer des exemples de données pour Spanner. L'accent mis par Machmeter sur les exemples axés sur les cas d'utilisation en fait un excellent point de départ pour générer des modèles de données structurellement similaires au schéma de production attendu. Les exemples fournis incluent des scripts pour les insertions groupées et d'autres opérations. Vous pouvez adapter les scripts pour générer des ensembles de données synthétiques à grande échelle. Pour en savoir plus, consultez le dépôt ou la documentation Machmeter.
QuickPerf
QuickPerf est distribué avec le pilote JDBC Spanner. QuickPerf fournit des scripts basés sur SQL qui créent rapidement des ensembles de données représentatifs pour tester l'intégrité du schéma et le comportement de la base de données. Il s'agit d'une option simple pour générer rapidement des ensembles de données de petite à moyenne taille et moins complexes.
Tests de charge
Les tests de charge vous permettent d'observer les performances de Spanner lors de la gestion des charges de travail afin de vous assurer que votre base de données dispose de la configuration optimale pour les exigences de production. Deux outils présentés précédemment, JMeter de Machmeter et QuickPerf, sont particulièrement efficaces pour simuler des charges de travail et mesurer des métriques de performances telles que le débit, la latence et l'utilisation des ressources.
Apache JMeter, amélioré grâce au projet Machmeter, fournit un framework puissant pour les tests de charge distribués avec Spanner. Machmeter inclut des configurations JMeter prédéfinies spécialement conçues pour simuler des charges de travail Spanner. Ces configurations peuvent être adaptées pour exécuter des requêtes, des transactions et des opérations par lot représentatives, ce qui vous permet de mesurer les performances de Spanner dans différents scénarios.
La capacité de JMeter à simuler des utilisateurs et des transactions simultanés en fait un bon choix pour tester l'évolutivité et la résilience de votre instance Spanner. Vous pouvez déployer JMeter en mode distribué à l'aide de Kubernetes ou du service géré GKE pour mettre à l'échelle votre environnement de test. Les résultats fournissent des informations sur la façon dont Spanner gère des charges de travail spécifiques, évolue en fonction de la demande croissante et fonctionne lors des pics de charge.
Pour en savoir plus et obtenir des exemples de configurations, consultez le dépôt Machmeter.
QuickPerf est un outil d'analyse comparative léger conçu pour tester les performances avec Spanner. Il se concentre sur la génération de métriques de performances avec une configuration minimale, ce qui vous permet d'itérer rapidement sur les optimisations. QuickPerf est facile à configurer et convient particulièrement aux tests à petite échelle et aux scénarios dans lesquels vous souhaitez mesurer rapidement l'impact sur les performances d'optimisations spécifiques de schémas ou de requêtes.
Bonnes pratiques pour les tests de charge
Lorsque vous effectuez des tests de charge, il est essentiel de suivre les bonnes pratiques de Spanner pour obtenir des résultats précis et exploitables.
- Période de préchauffage : accordez une période de préchauffage (généralement 30 minutes ou plus) à Spanner pour qu'il atteigne un état stable après le scaling des nœuds ou l'introduction d'une nouvelle charge de travail.
- Mesurez les métriques pertinentes : concentrez-vous sur les métriques telles que le débit (opérations par seconde), les centiles de latence (par exemple, p50, p95) et l'utilisation du processeur pour comprendre comment Spanner traite votre charge de travail.
- Exécutez des benchmarks longs : pour obtenir des résultats plus représentatifs, exécutez vos tests de charge pendant de longues périodes (par exemple, plus d'une heure) afin de tenir compte des comportements du système tels que le rééquilibrage et les tâches de maintenance en arrière-plan.
- Tests de scaling : testez les scénarios de scaling vertical et horizontal pour observer le comportement de Spanner avec différentes configurations de nœuds et charges maximales.
Vous pouvez utiliser des outils tels que JMeter, Machmeter et QuickPerf, ainsi que les bonnes pratiques pour les tests de charge, afin d'évaluer efficacement les performances de Spanner, d'identifier les goulots d'étranglement et d'optimiser votre base de données pour répondre aux exigences de votre charge de travail.
Surveillance
Pour démontrer efficacement les performances et l'évolutivité de Spanner lors d'un POC, en particulier sous charge, vous devez bien comprendre ses caractéristiques opérationnelles. Spanner fournit une suite complète d'outils de surveillance et de diagnostic conçus pour vous donner des informations précises sur tous les aspects des performances de votre base de données. Cet ensemble d'outils propose un large éventail de ressources, allant des tableaux de bord de métriques aux tables système détaillées, qui vous aident à identifier les goulots d'étranglement, à valider les choix de conception et à optimiser les performances.
Les insights système offrent une observabilité approfondie des performances et de l'état opérationnel d'une instance Spanner. Il fournit des métriques et des insights sur plusieurs domaines, y compris l'utilisation du processeur, la latence, le débit et plus encore, à des niveaux de précision ajustables. Lors d'un POC, il s'agit du point de départ pour observer le comportement de Spanner lors de vos tests. Les insights système vous permettent d'identifier rapidement les goulots d'étranglement des performances, comme une utilisation élevée du processeur ou une augmentation des latences de lecture ou d'écriture. Elle sert de base aux investigations ultérieures.
Les insights sur les requêtes offrent une vue descendante de l'exécution des requêtes. Ils permettent d'identifier les requêtes les plus fréquentes et les plus coûteuses en fonction de métriques telles que le temps CPU, le nombre d'exécutions et la latence moyenne. Les insights sur les requêtes vous permettent d'examiner en détail les plans d'exécution, y compris les statistiques pour chaque étape de la requête, et d'identifier les opérations spécifiques qui provoquent des ralentissements. Il propose également des fonctionnalités permettant d'analyser les tendances historiques des performances et de comparer les performances des requêtes sur différentes périodes. Cela vous aide à identifier les régressions ou l'impact des modifications apportées au schéma et au code. D'autres outils, tels que le conseiller d'index, analysent vos requêtes pour vous recommander des index nouveaux ou modifiés qui peuvent améliorer leurs performances.
Les insights sur les transactions offrent une visibilité sur les performances des transactions grâce à des métriques détaillées sur la latence des transactions, les temps d'attente des commits, le nombre de lignes et d'octets lus et écrits, ainsi que les participants aux transactions distribuées. Ces métriques révèlent une latence élevée ou des transactions abandonnées, et fournissent des détails sur leurs caractéristiques. Lors d'un test de charge POC, les insights sur les transactions sont essentiels pour évaluer l'efficacité transactionnelle du système sous contrainte. Il vous permet de surveiller et d'identifier toute dégradation à mesure que la charge augmente. L'analyse des transactions individuelles vous aide à identifier les causes des ralentissements, comme les transactions de longue durée qui bloquent les autres ou les transactions uniques qui lisent ou écrivent des volumes de données excessivement importants. Les informations issues des insights sur les transactions vous permettent d'effectuer un réglage ciblé, par exemple en optimisant les limites des transactions, en affinant les requêtes dans les transactions ou en ajustant le schéma pour réduire la quantité de données impliquées dans les transactions typiques. Cela garantit que le POC démontre la capacité de Spanner à maintenir la cohérence transactionnelle et les performances au niveau de charge attendu.
Les insights sur les verrous vous permettent de mieux comprendre le comportement de verrouillage des transactions. Ils vous aident ainsi à identifier et à résoudre les problèmes de conflit de verrouillage. Il fournit des informations sur les attentes de verrouillage, y compris les plages de clés de ligne spécifiques qui posent problème. Lors d'un test de charge POC, les insights sur les verrous sont essentiels pour déterminer si les conflits de verrouillage transactionnel entraînent des limites d'évolutivité. À mesure que la charge simultanée augmente, les transactions peuvent commencer à entrer en concurrence pour mettre à jour les mêmes données, ce qui entraîne une augmentation des temps d'attente et une diminution du débit. Ces informations vous aident à optimiser le schéma, à modifier les limites des transactions et à ajuster la logique de l'application. Ces actions atténuent la contention et garantissent que la base de données Spanner maintient ses performances sous la charge de travail prévue, ce qui évite toute dégradation due aux mécanismes de verrouillage.
Les insights sur les hotspots identifient les goulots d'étranglement des performances, en particulier l'augmentation de la latence, qui résultent des conditions de hotspotting. Les points chauds se produisent généralement en cas de charge élevée et inégale. Les causes des hotspots sont souvent les suivantes :
- Conception de schéma non optimale
- Sélection de la clé primaire
- Modèles d'accès qui concentrent les opérations sur un petit sous-ensemble de données plutôt que de les répartir de manière uniforme entre les nœuds
Lors d'un test de charge POC, les insights sur le hotspotting vous aident à décider où optimiser votre schéma. Par exemple, vous devrez peut-être ajuster les clés primaires ou modifier les index secondaires pour éviter les points chauds.
Key Visualizer fournit une représentation visuelle des modèles d'utilisation de la base de données au fil du temps dans l'ensemble de l'espace de clés des tables et des index. Il génère des cartes de densité qui montrent l'activité de lecture et d'écriture, en mettant en évidence les zones de forte intensité et les schémas potentiellement problématiques. Lors d'une preuve de concept, cet outil permet de valider la conception du schéma et d'identifier les éventuelles limites d'évolutivité. À mesure que la charge augmente, vous pouvez observer comment la charge de travail est répartie dans votre espace de clés et les tables et index correspondants.
Les tables d'introspection, principalement son système de tables Spanner_SYS, fournissent une multitude d'informations sur l'état interne et les performances de la base de données. Ces tables présentent des statistiques détaillées sur l'exécution des requêtes, le comportement des transactions, les conflits de verrouillage et les détails du schéma. Lors d'un test de charge POC, ces tables d'introspection fournissent une approche axée sur les données pour le diagnostic des performances, au-delà de ce que proposent les outils d'insights mentionnés précédemment. Par exemple, vous pouvez les utiliser pour résoudre la cause première des conflits de verrouillage dans votre base de données, qui sont autrement difficiles à détecter, et obtenir des insights exploitables pour l'optimisation.
Optimisation
Les tests de charge sont une étape essentielle pour identifier les problèmes de performances et les goulots d'étranglement potentiels dans votre implémentation Spanner. Les insights obtenus à partir de ces tests doivent guider les efforts d'optimisation concernant la conception du schéma, le comportement des transactions et les performances des requêtes pour s'assurer que Spanner répond aux exigences de votre charge de travail.
Optimiser la conception du schéma
Bien qu'une conception de schéma initiale soit basée sur les bonnes pratiques en matière d'évolutivité et de performances, l'exécution de charges de travail dans des conditions réelles révèle souvent des domaines nécessitant des améliorations. Les tests de charge fournissent des informations précieuses sur les performances du schéma dans des conditions spécifiques. Ils mettent en évidence des problèmes tels que les points sensibles, la distribution inégale des données ou les inefficacités dans les performances des requêtes.
L'optimisation consiste à affiner les domaines suivants pour les adapter aux caractéristiques de la charge de travail de votre application.
- Ajustements de la clé primaire : si les tests de charge révèlent des points chauds ou une distribution de données déséquilibrée, examinez la conception de la clé primaire. Par exemple, envisagez d'ajouter de l'aléatoire dans le préfixe de clé pour répartir les données de manière plus uniforme sur les nœuds tout en préservant l'efficacité des requêtes.
- Affinement des index : les tests de charge peuvent révéler si des index redondants ou une sur-indexation affectent négativement le débit en écriture. Supprimez les index inutiles ou restructurez ceux existants pour améliorer les performances des requêtes. Évaluez la sélectivité des index et assurez-vous qu'ils correspondent aux modèles de requête typiques.
- Tables et hiérarchies entrelacées : analysez si les tables associées peuvent bénéficier de l'entrelacement des tables pour réduire la latence des requêtes. Ajustez les décisions d'entrelacement en fonction des schémas d'accès observés lors des tests. À l'inverse, envisagez de modéliser ces tables séparément si la structure hiérarchique entraîne une surcharge inattendue.
Pour savoir comment créer des schémas évolutifs, consultez les bonnes pratiques de conception de schémas Spanner.
Optimiser la sémantique et les requêtes de transaction
Les tests de charge mettent souvent en évidence des inefficacités dans l'exécution des transactions et des requêtes, telles que des problèmes de contention ou de verrouillage élevés. Optimisez la sémantique des transactions et les structures de requêtes pour maximiser le débit et minimiser la latence :
- Modes de transaction : utilisez le mode de transaction approprié pour chaque opération de charge de travail. Par exemple, utilisez des transactions en lecture seule pour les requêtes qui ne modifient pas les données, ou le langage LMD partitionné pour les mises à jour et les suppressions groupées.
- Regroupement par lot : dans la mesure du possible, utilisez des opérations d'écriture par lot pour réduire les frais généraux occasionnés par plusieurs aller-retours.
- Optimisation des requêtes : refactorisez les requêtes pour n'inclure que les colonnes et les lignes nécessaires, profitez des index et utilisez les paramètres de requête dans votre application pour réduire la surcharge.
Pour en savoir plus sur les stratégies d'optimisation, consultez Présentation des transactions et Bonnes pratiques SQL.
Tests de charge itératifs
L'optimisation est un processus itératif. Effectuez des tests de charge après chaque modification importante du schéma ou de la requête pour valider les améliorations et vous assurer qu'aucun nouveau goulot d'étranglement n'est introduit.
Simulez des scénarios d'application réalistes avec différents niveaux de simultanéité, types de transactions et volumes de données pour confirmer que Spanner fonctionne comme prévu dans des conditions de pic et d'état stable.
Métriques clés à surveiller
Suivez les métriques clés telles que la latence (p50, p99), le débit et l'utilisation du processeur pendant l'optimisation.
Étapes suivantes
- Regardez Planifier et exécuter un contact Spanner pour découvrir les étapes essentielles, les bonnes pratiques et les outils dont vous avez besoin pour évaluer efficacement les capacités de Spanner.