[COMPASS-6212] Investigate changes in PM-2015: Remove restrictions and increase performance of shard key updates Created: 17/Oct/22 Updated: 19/Oct/22 Resolved: 19/Oct/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 Details will be hashed out in the scoping and designing Description of Linked TicketEpic Summary SummaryAllow batches of size > 1 for updates that modify a document’s owning shard and improve their latency and throughput. MotivationMongoDB 4.2 introduced the ability to atomically change the shard key value of a document. This feature requires the update (or findAndModify) command to be run as a retryable write or within a multi-document transaction. However, it has a limitation where the bulk update command must contain only a single operation. This restricts the valid update commands an application or driver can send to a sharded cluster. In preparation for the world where users no longer choose their own shard key, it must be possible for applications and drivers to send these kinds of update commands to a sharded cluster without error. Additionally, the current implementation of document shard key modifications is driven entirely by MongoS and as such it has 2 major performance drawbacks:
The ability to update a document’s shard key has spiked a number of interesting use-cases that customers are trying to implement:
DocumentationScope Document |