[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:
Depends
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 Ticket

Epic Summary

Summary

Introduce the ability to change the shard key of an existing sharded collection.

Motivation

Sharding 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

  • Product Owner: Garaudy Etienne
  • Project Lead: Max Hirschhorn
  • Program Manager: Ratika Gandhi
  • Drivers Contact:

Documentation

Product Description
Scope Document
Technical Design Document


Generated at Wed Feb 07 22:42:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.