[SERVER-34559] Explore options for capped collection performance improvements Created: 19/Apr/18 Updated: 05/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage, WiredTiger |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Alexander Gorrod | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
At the moment capped collections generally end up removing a small number of documents at a time when they reach the capped size. We had success with optmizing how the oplog maintains it's size, by removing a larger volume of entries at a time. We could make capped collections much faster by making a similar change, and removing a proportion of the documents to maintain the collection size. There are references in the code to count based capped collections requiring, but our documentation doesn't mention that requirement, in fact it says that the size restriction means we don't guarantee that the count will be accurately maintained. |
| Comments |
| Comment by Connie Chen [ 27/Jan/22 ] |
|
Putting this back into Triage as we are closing PM-223 as we are no-longer deprecating capped collections |
| Comment by Alexander Gorrod [ 11/May/18 ] |
|
Capped collections are not a preferred method for maintaining a bounded collection (use TTL indexes), so I'm moving this optimization ticket to the backlog. |