Exam AZ-304 topic 10 question 2 discussion

Correct Table with fixed capacity: in requirements - "The data in the Azure Table storage is 50 GB and is not expected to increase" Additional read region: availiability zone or set doesn't help during region gailure

Multiple tables fixed capacity

Multiple table fix capacity - due to performance issue in current system Additional read regions

Correct

Given Answers are correct.

"The data in the table storage is 50 GB and is not expected to increase" "queries frequently cause table scans" 1st drop down is multiple tables with fixed capacity 2nd drop down is additional read region for sure

The 1st box should be multiple tables with fixed size. The question is asking to address performance issue in Azure Table Storage. So we should understand what caused performance issue first. It says it's caused by table scan. The issue of a table scan has to do with crossing the partition boundaries. The level of performance you are guaranteed is explicitly set at the partition level. therefore, when you run a full table scan, its a) not very efficient, b) doesn't have any guarantee of performance. This is because the partitions themselves are set on separate storage nodes, and when you run a cross partition scan, you're consuming potentially massive amounts of resources (tying up multiple nodes simultaneously). Therefore the solution after migrating to Cosmos DB is to reduce partition keys. You then need multiple tables as new design for Cosmos migration.

came in exam on 20-sep-21, I passed, I choose Multiple tables fixed capacity, second one additional read region

Correct answer: table that has unlimited capacity. Requirements say that there is one 50GB table. So - why shall we spread it to many tables? It doesn't have any sense. The table can't be fixed. Because fixed table in cosmos has to be <=10GB.

As a solution a single table will work better than multiple tables. However, the answer should be, "Multiple tables that have fixed capacity". The reason is to satisfy the requirements: 1. Payment processing system must be able to use grouping and joining tables on encrypted columns. 2. Minimize the effort required to modify the .NET web service querying Azure Cosmos DB. Requirement 1, is self-explanatory it tells you you need multiple tables. Or another way to interpret that statement is the "existing" solution relies on multiple tables. Requirement 2, tells you you need to minimize the effort. Imagine going from a multi-table solution to a single table solution, the query changes you have to make in the existing code. Although it's technically feasible and arguably make the queries more efficient (going to a single table design) it doesn't satisfy the requirement.

Requirement is to migrate to Cosmos. Cosmos table storage has no limits on table size, and all attributes of an entity are indexed by default (https://docs.microsoft.com/en-us/azure/cosmos-db/table-api-faq#does-the-table-api-index-all-attributes-of-an-entity-by-default-).

Multiple tables seams the best answer as of: "A table is made up of one or more partitions, and many of the design decisions you make will be around choosing a suitable PartitionKey and RowKey to optimize your solution. A solution can consist of just a single table that contains all your entities organized into partitions, but typically a solution has multiple tables. Tables help you to logically organize your entities, and help you manage access to the data by using access control lists. You can drop an entire table by using a single storage operation." REF: https://docs.microsoft.com/en-us/azure/cosmos-db/table-storage-design-guide

Incorrect Multiple tables fixed capacity

sizing requirements should be multiple tables that have fixed capacity. https://docs.microsoft.com/en-us/azure/cosmos-db/table-storage-design-guide

So for the sizing part, is it "one table with fixed capacity" or "multiple tables with fixed capacity"? For resiliency: Cosmos DB doesnt have something like "availabiliy set", this is only for e.g. VMs. "availability zone" provides only redundancy within a region. So "additional read region" is correct.

Correct

Correct data stored on Azure Tables does not depend on complex server-side joins or other logic