Gestisci un'applicazione Bigtable sensibile alla latenza (letture/scritture miste) e hai bisogno di una scansione analitica oraria dell'intera tabella senza impattare la produzione. Cosa dovresti fare?

La risposta corretta è aggiungere un secondo cluster a un'istanza esistente con routing single-cluster. Bigtable supporta più cluster all'interno della stessa istanza. Creando un secondo cluster e configurando un profilo di app separato (ad esempio, batch-analytics) per il routing a questo nuovo cluster, è possibile isolare il carico di lavoro analitico dal traffico di produzione. Il routing single-cluster assicura che le letture e le scritture dal profilo batch-analytics vadano solo al nuovo cluster, prevenendo impatti sul cluster di produzione. Il profilo live-traffic continuerebbe a servire il carico di lavoro sensibile alla latenza sul cluster originale. Esportare il dump su GCS introdurrebbe latenza e complessità per una scansione oraria. Aumentare le dimensioni del cluster esistente non isolerebbe il carico di lavoro e potrebbe comunque influire sulla latenza. L'opzione con routing multi-cluster non è l'ideale perché le scritture verrebbero replicate su entrambi i cluster, e le letture potrebbero essere servite da entrambi, potenzialmente influenzando il cluster di produzione.