Exam DP-201 All Questions

View all questions & answers for the DP-201 exam

Exam DP-201 topic 1 question 33 discussion

Actual exam question from Microsoft's DP-201

Question #: 33
Topic #: 1

HOTSPOT -
You are designing a solution that will use Azure Table storage. The solution will log records in the following entity.

You are evaluating which partition key to use based on the following two scenarios:
✑ Scenario1: Minimize hotspots under heavy write workloads.
✑ Scenario2: Ensure that date lookups are as efficient as possible for read workloads.
Which partition key should you use for each scenario? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
Hot Area:

Show Suggested Answer

Suggested Answer:

References:
https://docs.microsoft.com/en-us/rest/api/storageservices/designing-a-scalable-partitioning-strategy-for-azure-table-storage

by zb99 at April 15, 2020, 7:37 p.m.

Comments

Submit Cancel

Yuri1101

Highly Voted 5 years, 2 months ago

Scenerio1: DepartmentName+EmployeeID

upvoted 78 times

JamesCho

5 years, 1 month ago

Even if 1-2 departments have more employees than other departments, practically not all employees will not sign-up for events all at a time.

upvoted 1 times

...

vistran

5 years, 1 month ago

thats the answer as per https://docs.microsoft.com/en-us/azure/cosmos-db/table-storage-design-guide#solution-11

upvoted 20 times

Treadmill

4 years, 10 months ago

Scenario 1: Department+EmployeeID = avoids hotspots on inserts which happen at the same time Scenario 2: Year+month+day+hour+EventID = date is included as a string for date lookups Wrong Datetime: The partition key value (For example: "Andrew"). The partition key value can be of string or numeric types. https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview https://docs.microsoft.com/en-us/azure/cosmos-db/table-storage-design-guide#solution-11

upvoted 23 times

...

groy

Highly Voted 4 years, 9 months ago

Correct final answers.....!! 1: Department+EmployeeID = avoids hotspots on inserts which happen at the same time 2: Year+month+day+hour+EventID = date is included as a string for date lookups

upvoted 43 times

...

Pairon

Most Recent 4 years, 3 months ago

I agree with the given answer. "You could also partition your data by a Date or DateTime attribute (or some part of)." (https://trycatch.me/data-partitioning-strategy-in-cosmosdb/), so datetime field can be used as partition key.

upvoted 2 times

...

Pairon

4 years, 3 months ago

Not sure about DepartmentName+EmployeeID: the department name could change.

upvoted 2 times

...

AhmedReda

5 years ago

For Scenario 2 : is it Year-Month-Day-Hour-EventID ??

upvoted 2 times

...

Abhilvs

5 years ago

The timestamp is of milliseconds precision, in that case, it won't lead to hot partitions.

upvoted 2 times

Ash666

4 years, 10 months ago

Can’t set date time type as partition key. Either string or numeric type.

upvoted 4 times

...

Mathster

5 years, 1 month ago

Surname cannot be a partition key because ~750 records have a null value.

upvoted 1 times

...

azurearch

5 years, 1 month ago

choosing timestamp would create multiple partitions and affects insert operations. composite key could be the right choice here

upvoted 1 times

...

Tombarc

5 years, 2 months ago

DepartmentName+EmployeeID could still result in hot partitions as there might be departments with many more employees than others. I'd say both scenarios would have a combination of "Year+month+day+hour_EventID" to suffice the requirements, and then a "rowkey" would be used to distinguish between the two. https://docs.microsoft.com/en-us/rest/api/storageservices/designing-a-scalable-partitioning-strategy-for-azure-table-storage#r

upvoted 7 times

azurearch

5 years, 1 month ago

the scenario is for write heavy workload, on a certain hour there could be many events causing hot spots.

upvoted 1 times

...

azurearch

5 years, 1 month ago

for each event it would be return in a separate partition since we are adding event id to the partition key. that would introduce write latency. dept + empid makes logical. can be the answer.

upvoted 2 times

...

zb99

5 years, 2 months ago

Timestamp would actually be the worst possible partition option for hotspots. Will result in automatic range partitioning, causing all writes to go to a single partition: https://docs.microsoft.com/en-us/rest/api/storageservices/designing-a-scalable-partitioning-strategy-for-azure-table-storage

upvoted 6 times

apz333

5 years, 2 months ago

Besides, you have to use string values for PartitionKey, and "EventTimestamp" is a datetime type. I don't think you could use it at all unless you convert it to string.

upvoted 2 times

...