Vous exécutez une application Bigtable sensible à la latence (lectures/écritures mixtes) et avez besoin d'une analyse horaire de la table complète sans impacter la production. Que devez-vous faire ?

La bonne approche consiste à ajouter un second cluster à l'instance Bigtable existante avec un routage mono-cluster et à utiliser des profils d'application distincts. Le routage mono-cluster garantit que le trafic de chaque profil d'application est dirigé vers un cluster spécifique. Le profil d'application de trafic en direct dirigera les opérations de lecture/écriture sensibles à la latence vers le cluster de production, tandis que le profil d'analyse par lots dirigera les requêtes analytiques vers le nouveau cluster, isolant ainsi la charge de travail et évitant d'impacter la production. Exporter le dump Bigtable vers GCS puis l'analyser introduirait une latence significative et ne permettrait pas une analyse horaire en temps quasi réel. Ajouter un second cluster avec un routage multi-cluster ne garantirait pas l'isolation du trafic, car les requêtes pourraient être acheminées vers n'importe quel cluster. Augmenter la taille du cluster existant ne résoudrait pas le problème d'isolation des charges de travail et pourrait toujours entraîner des interférences entre les opérations de production et analytiques.