Как вложенные структуры влияют на производительность запросов DocumentDB?

В противном случае вопрос можно было бы сформулировать следующим образом: "сглаживать или не сглаживать?"

Если бы я хранил вложенные JSON-документы в коллекции DocumentDB, выполнял бы запрос через эти вложенные структуры наравне с сохранением этих вложенных структур в отдельной коллекции в виде плоских документов самостоятельно?

Данные, о которых идет речь, будут записаны один раз и (вероятно) никогда не будут обновлены. Отчет о результатах работы находится в верхней части списка требований.

С одной стороны, хранение данных во вложенной структуре кажется "правильным" способом использования технологии no-schema / no SQL. То есть мы, естественно, хотим связать заголовочные данные с подробными данными в одном месте и в контексте. Но может ли он масштабироваться и продолжать работать, когда мы пишем тысячи строк в минуту и одновременно запускаем отчеты по этой коллекции из веб-приложения?

Или, может быть, лучше сгладить эти подробные данные, избыточно сохраняя соответствующие части данные заголовка в каждой строке коллекции деталей? Как давний разработчик / пользователь СУБД, я склонен не хранить данные избыточно, но должен ли я отказаться от этой идеи в пользу высокой производительности?

Делает ли плоская структура данных запрос более эффективным в DocumentDB и на сколько маржи? То есть, от чего я отказываюсь, делая это, и стоит ли это того, если производительность является главным (но не единственным) приоритетом?