Я не знаю, как работает сервер в этом случае, но я ожидаю, что по причинам кэширования сервер будет загружать полные документы в память при чтении их с диска. Чтение с диска происходит очень медленно (= требует много времени), и я ожидаю, что сервер будет активно использовать память, если сможет избежать чтения.
Важное замечание здесь заключается в том, что документы хранятся на диске в виде списков ключей. пары значений, составляющие их содержимое. Чтобы не загрузить поле с диска, серверу пришлось бы перестроить рассматриваемый документ как часть его чтения, так как в него включены поля длины. Я не вижу, чтобы это происходило на практике.
Итак, как только документы находятся в памяти, я предполагаю, что они находятся там со всеми их полями, и я не думаю, что вы можете настроить это.
Когда вы запрашиваете, сервер может или не может удалить отдельные поля, но это только изменит требования к памяти для конкретного запроса. Как правило, эти требования к памяти затмеваются общим размером кэша базы данных и конвейерами агрегации. Поэтому я не думаю, что на самом деле имеет значение , в какой момент большое поле удаляется из документа во время обработки запроса (при условии, что вы проецируете его в запросе).
Я думаю, что это не так Не стоит пытаться обдумывать / оптимизировать. Если у вас есть реальная система с реальными рабочими нагрузками, вам будет гораздо сложнее оптимизировать что-то еще.
Если вы беспокоитесь об использовании памяти, когда объем доступной памяти имеет размер потребителя (скажем, до 16 gb), просто получите больше памяти - это безумно дешево, учитывая, сколько времени вы бы потратили на работу из-за ее нехватки (говорим ли мы о предоставлении больших экземпляров AWS или покупке большего количества оперативной памяти).