You're using Bigtable for a real-time application, and you have a heavy load that is a mix of read and writes. You've recently identified an additional use case and need to perform hourly an analytical job to calculate certain statistics across the whole database. You need to ensure both the reliability of your production application as well as the analytical workload.
What should you do?
To ensure both the reliability of your production application and the analytical workload, it's best to add a second cluster to your existing Bigtable instance with multi-cluster routing. This allows for automatic failover to the nearest available cluster if one cluster becomes unavailable, ensuring high availability and reliability for both your production and analytical tasks. Using the live-traffic app profile for regular workloads and the batch-analytics profile for analytics helps isolate workloads and maintain performance.
Answer is C When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users. https://cloud.google.com/bigtable/docs/replication-overview#use-cases
Agreed :)
"When you use a single cluster", here we are creating a 2nd cluster, so we'll be using 2 different clusters. We want to redirect analysis jobs to the 2nd cluster, and the other job to the 1st cluster. Thus, I think that D is more adequate
Option D didnt say to create a new cluster, rather it said to increase the size of the cluster. There is a difference. Hence c is the correct answer to run the batch processing in a single cluster mode
It was actually illustrated here https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve
Option B is correct An app profile specifies the routing policy that Bigtable should use for each request. Single-cluster routing routes all requests to 1 cluster in your instance. If that cluster becomes unavailable, you must manually fail over to another cluster. Multi-cluster routing automatically routes requests to the nearest cluster in an instance. If the cluster becomes unavailable, traffic automatically fails over to the nearest cluster that is available. Bigtable considers clusters in a single region to be equidistant, even though they are in different zones. You can configure an app profile to route to any cluster in an instance, or you can specify a cluster group that tells the app profile to route to only some of the clusters in the instance. Cluster group routing sends requests to the nearest available cluster within a cluster group that you specify in the app profile settings. Reference:-https://cloud.google.com/bigtable/docs/app-profiles#routing
C. This is exactly the example in the documentation. https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve
Correct 2 jobs >> 2 cluster 3 jobs >> 3 cluster app profiles with single-cluster routing used to route to specific cluster Job1 >> Cluster 1 Job2 >> Cluster 2 .....
It's B https://cloud.google.com/bigtable/docs/replication-overview#app-profiles https://cloud.google.com/bigtable/docs/replication-overview#routing-policies
https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve "When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users." It is C.
Answer is C "When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users." https://cloud.google.com/bigtable/docs/replication-overview#batch-vs-serve
C is the answer. https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users.
When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users. Single cluster routing - You can use single-cluster routing for this use case if you don't want your Bigtable cluster to automatically fail over if a zone or region becomes unavailable. Multi-cluster routing - If you want Bigtable to automatically fail over to one region if your application cannot reach the other region, use multi-cluster routing.
https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve
I see what you say on C but the question states high availability how do you handle that with option C when you have a single region cluster hence answer needs to be with multi-region cluster - To configure your instance for a high availability (HA) use case, create a new app profile that uses multi-cluster routing, or update the default app profile to use multi-cluster routing.
i meant single-cluster routing
It actually addresses the issue of High availability in that same link if you scroll down a bit more. https://cloud.google.com/bigtable/docs/replication-settings#high-availability
IIt is C: "Workload isolation: Using separate app profiles lets you use different routing policies for different purposes. For example, consider a situation when you want to prevent a batch read job (workload A) from increasing CPU usage on clusters that handle an application's steady reads and writes (workload B). You can create an app profile for workload B that routes to a cluster group that excludes one cluster. Then you create an app profile for workload A that specifies single-cluster routing to the cluster that workload B doesn't send requests to. You can change the settings for one application or function without affecting other applications that connect to the same data." https://cloud.google.com/bigtable/docs/app-profiles
C - "With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users." - https://cloud.google.com/bigtable/docs/replication-overview#batch-vs-serve
Answer is C
I am going for C?
Answer B: reason 1: If you don' t have any cost constraint use multi-cluster routing, reason 2: Single cluster is less scalable as we need high scalability i would go with B
B is correct. Two different job profiles to redirect trafiic to two different cluster. C is incorrect because there is no tpoint in creating app profile for two different workloads in the same cluster. One cluster handles writes and another handle reads.
B better than C. Multi-cluster routing to handle failovers automatically. Reference: https://cloud.google.com/bigtable/docs/replication-settings#regional-failover