[SERVER-44193] Remove Top Chunk Optimisation Created: 24/Oct/19  Updated: 06/Dec/22  Resolved: 03/Mar/22

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-44192 Introduce metrics to measure the usef... Closed
Duplicate
duplicates SERVER-61557 Get rid of top chunk migration Closed
Related
Assigned Teams:
Sharding EMEA
Participants:

 Description   

The so called "Top Chunk Optimisation" in Sharding operates by checking whether writes are happening to the highest (or lowest) chunk of a collection and pre-splitting and possibly moving that chunk to a different shard. This is done in order to ensure that the "top chunks" are moved while empty (or as small as possible), rather than when they are full of data.

Given that it only looks at the extreme chunks of the collection, the top chunk optimisation appears to only be useful for the cases where the collection is bulk-loaded, on a single thread, using data sorted on the shard key.

Without this pattern, the top chunk optimisation is largely unused and in certain cases causes issues, because it would block the threads performing inserts to the extreme chunks. The blocking issue was mostly fixed in 4.2 by moving the auto-splitter to the shard servers and making it asynchronous, but in older versions it still persists.

This ticket is to design and introduce a flag to disable the TCO.



 Comments   
Comment by Pierlauro Sciarelli [ 03/Mar/22 ]

Closing because - now that the title has been renamed - this ticket became a duplicate of SERVER-61557.

Generated at Thu Feb 08 05:05:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.