[SERVER-61587] Research potential improvements in document validation for storage Created: 18/Nov/21 Updated: 25/Jul/23 Resolved: 25/Jul/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Nikita Lapkov (Inactive) | Assignee: | Backlog - Query Execution |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
MongoDB uses DeltaExecutor::applyUpdate to apply diff updates to the document. For example, secondaries in the replica set use it to apply oplog entries. One of the steps of DeltaExecutor::applyUpdate execution is validation of the result. It happens in the call to storage_validation::scanDocument. This validation consists of several parts:
There are two flags controlling the validation stages:
Since all validation checks are performed in one method storage_validation::scanDocument, we call it if either of this flags is set. Validation can be time-expensive operation for large documents. We have noticed significant improvements by optimizing and skipping some of the validation (see The main goal of this ticket is to research if there are any workloads where further optimization of validation can benefit performance. If such workloads exist, we can try to split the validation in 2 parts: first 3 checks and the last check. There are several reasons we could want to do that:
|
| Comments |
| Comment by Ana Meza [ 25/Jul/23 ] |
|
During Quick Wins Triage the team decided to close this ticket as Won't Do |