Cette checklist avant lancement répertorie les points à prendre en compte avant de lancer une application de production sur Spanner. Elle n'est pas exhaustive, mais sert à mettre en avant les domaines susceptibles d'avoir des répercussions importantes sur les performances de production.
Choisir une configuration d'instance appropriée
Choisissez une configuration d'instance (régionale ou multirégionale) correspondant à vos besoins.
Si vous choisissez des types d'instances multirégionaux, l'application qui accède à Spanner doit se trouver à proximité de la région principale. Pour en savoir plus, consultez la page Instances.
Concevoir un schéma pour des performances à grande échelle
Le schéma de données relationnelles de Spanner est semblable à celui des bases de données relationnelles traditionnelles, avec quelques nuances à prendre en compte:
- Utilisez les tables entrelacées plutôt que les relations de clé étrangère, le cas échéant.
- Choisissez une clé primaire qui empêche les points d'accès.
- Assurez-vous que les index secondaires ne créent pas de points d'accès (similaires aux points d'accès de clés primaires).
- Créez des index secondaires et stockez les colonnes associées, si nécessaire.
- Limitez la taille des lignes.
Comprendre les facteurs de performance
Avec la segmentation automatique et les données stockées par la suite, plus la requête est ciblée, plus elle est performante. Réduire la valeur à un seul parent entrelacé et tous ses enfants offre de meilleures performances que les requêtes ou les opérations affectant plusieurs lignes.
Nous vous recommandons vivement d'effectuer des analyses comparatives et des tests à grande échelle afin de détecter les problèmes et les goulots d'étranglement avant le lancement. Spanner fournit des plans d'exécution de requêtes pouvant être utilisés avec des tables lors de la conception du schéma pour comprendre le fonctionnement probable des requêtes.
Autres facteurs de performances à prendre en compte :
- Préférez les transactions en lecture seule aux transactions en lecture/écriture plus coûteuses lorsque vous n'écrivez pas de données.
- Concevez votre application de sorte à réduire le nombre de participants répartis dans une transaction. Spanner peut effectuer des transactions sur plusieurs lignes sur différents serveurs. Toutefois, en règle générale, les transactions qui affectent de nombreuses lignes colocalisées sont plus rapides et moins coûteuses que les transactions qui affectent de nombreuses lignes dispersées dans la base de données ou dans une grande table.
- Utilisez des paramètres de requête plutôt que des littéraux de chaîne pour améliorer les performances de la requête et la surveillance des statistiques.
Comprendre les limites et quotas
Pour des raisons d'architecture, et pour maintenir ses performances élevées et sa redondance, Spanner dispose de certains quotas et limites qui doivent être pris en compte lors de la conception de l'application. Les quotas peuvent être augmentés avec un délai de livraison.
Par exemple, il existe une limite de 80 000 mutations par commit, et un maximum de 15 jointures par requête.
Ces limites, ainsi que la conception de schéma et la prévention contre les points d'accès, ont des répercussions sur le chargement groupé. Par conséquent, vous devez suivre les bonnes pratiques de chargement groupé.
S'assurer que la surveillance est en place
Configurez Cloud Monitoring pour vous avertir lorsque vous approchez de vos limites
Augmentez la capacité de calcul si vous atteignez les métriques de performances pour le scaling linéaire de vos instances Spanner. Nous vous recommandons de maintenir l'utilisation du processeur en dessous de 65 % pour les instances régionales et en dessous de 45 % pour les instances multirégionales.
Utilisez les modèles de requête sur la page Requête d'une base de données pour surveiller les statistiques des requêtes dans les tables de statistiques sur les requêtes.
Définir une stratégie de migration des données (si nécessaire)
Le chargement groupé des données dans Spanner doit tenir compte de l'architecture distribuée pour maintenir les performances:
- Partitionner les données par clé primaire
- Éviter les refus de transaction et surveiller l'utilisation du processeur
- La création d'index secondaires après le chargement des données est généralement plus rapide
Cet article de blog est un bon exemple de mise en œuvre d'écritures à haut débit.
S'assurer que la configuration de la sécurité est en place
Configurez des rôles IAM pertinents pour gérer la sécurité au niveau des bases de données et de l'instance. La sécurité au niveau des tables doit être gérée dans l'application.
Connaître les options d'assistance
Assurez-vous de disposer d'une stratégie permettant d'obtenir de l'aide.