[COMPASS-6350] Investigate changes in PM-234: Resharding Created: 06/Dec/22 Updated: 14/Dec/22 Resolved: 14/Dec/22 |
|
| Status: | Closed |
| Project: | Compass |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | No version |
| Type: | Investigation | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Documentation Changes: | Not Needed | ||||
| Description |
|
Original Downstream Change Summary We have completed Resharding work on Server. Flagging downstream teams as an FYI Description of Linked TicketEpic Summary SummaryIntroduce the ability to change the shard key of an existing sharded collection. MotivationSharding enables workloads to achieve write scalability at the expense of additional latency by splitting up the data onto separate shards. Data access patterns within a user's application have varying levels of sensitivity to additional latency. The level of sensitivity influences the possible partitioning schemes and determines what additional latency for each data access pattern is acceptable. Moreover, the desired Serverless UX requires the Atlas team to be able to choose a shard key without prompting the user. Such an automated system can unknowingly make an undesirable trade-off for the user, or can learn later on that the application’s query shapes have changed. Thus, for such an automated system to be self-correcting, we would need the possibility to change the shard key of an existing sharded collection while having a minimal negative impact on the workload being run. Cast of Characters
DocumentationProduct Description |