[SERVER-1810] ability to set minimum allocation size per collection Created: 19/Sep/10 Updated: 08/Feb/23 Resolved: 14/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 51 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
With the ability to set a minimum allocation size, and power of 2 allocation, you have very good control over allocation, will greatly reduce the number of moves, and have very little to no fragmentation. |
| Comments |
| Comment by Asya Kamsky [ 07/Mar/15 ] |
|
Note that specifying initial size would not have helped in this case:
since they would have had to know in advance that they will need to add specific size field(s) in the future when the collection was created. |
| Comment by Paul Reinheimer [ 19/May/13 ] |
|
With https://jira.mongodb.org/browse/SERVER-8775?focusedCommentId=338871#comment-338871 this seems even more important. I have documents that change size radically between initial insert, and final update (~20 seconds later). I'd love to give mongo guidance on how big that document is going to get. Specifying an initial size seems better to me. With documents that start quite small the padding factor could swing radically based on small changes there. |
| Comment by Eliot Horowitz (Inactive) [ 03/Feb/12 ] |
|
Still not 100% sure of the right design. Might be better to have an initial size than padding factor. Want to have the right option - not too many. |
| Comment by Antoine Girbal [ 19/Jan/12 ] |
|
note about a recent problematic case:
User was surprised that such a small change would kill db. |
| Comment by Dwight Merriman [ 03/Sep/11 ] |
|
i wonder if a knob is needed, or rather if it just needs be more intelligent. it may be needed – a bulk import scenario comes to mind. |
| Comment by Liu Qishuai [ 17/Jun/11 ] |
|
it's better to have three values for default/min/max. the default was 1.0/1.0/2.0 |
| Comment by ganesan pandurangan [ 16/Jun/11 ] |
|
will this factor override the default behavior ? Lets say I configure padding factor for a collection as 1.5 and in reality the new documents are larger than expected, will mongo still be able to adapt and set the padding factor as say 2.0 and discard what user has set ? |
| Comment by Kenny Gorman [ 11/Apr/11 ] |
|
+1 on this being configured in a simple way per collection. |
| Comment by Eliot Horowitz (Inactive) [ 21/Sep/10 ] |
|
Correct - per collection. |
| Comment by Thilo Planz [ 19/Sep/10 ] |
|
This would be per collection, right? And ideally it could be also changed for collections that already have data (then affecting only newly added/relocated records). |