Ценообразование Firestore для чтения ОДНОГО документа не является ни функцией коллекции (или подколлекции), содержащей документ, ни функцией подколлекций, содержащихся в документе.
Как вы можете прочитать в ответе / вопросе SO, на который вы ссылаетесь, «Запросы в Firestore всегда« поверхностные »», что означает, что когда вы читаете документ, вы платите за прочитанный документ, но не платите за документы, находящиеся в его подпункте. -collection (s).
Стоит отметить, что концепция подбора может быть немного "вводящей в заблуждение".
Давайте рассмотрим пример: представьте себе документ doc1 в коллекции col1
col1/doc1/
и еще один subDoc1 в коллекции subCol1 (под)
col1/doc1/subCol1/subDoc1
На самом деле, с технической точки зрения, эти две коллекции (col1 & subCol1) вовсе не связаны друг с другом . Они просто разделяют часть своего пути, но больше ничего. Одним из побочных эффектов этого является то, что если вы удаляете документ, его подгруппа (ы) все еще существует.
Итак, чтобы ответить на ваши вопросы:
У меня есть коллекция с 2 различными коллекциями внутри, увеличу ли я все x3?
Это зависит от того, что именно вы прочитали. Если вы читаете только документы из первой (родительской) коллекции, вы будете платить только за чтение этих документов. Вы будете платить только за документы, содержащиеся в двух вложенных коллекциях, если вы создадите два дополнительных запроса для чтения документов в этих двух вложенных коллекциях. Опять же, вам просто нужно считать эти три (под) коллекции полностью независимыми, и поэтому вы платите за каждый документ, который вы читаете в каждой из этих коллекций.
Было бы лучше переместить все к первой коллекции в виде единого документа
Это действительно зависит от вашей модели данных и от запросов, которые вы планируете выполнить. Абсолютно возможно «переместить все в одном документе», но вы должны позаботиться о некоторых ограничениях, в частности, о максимальном размере документа, который составляет 1 МБ.
Кроме того, если ваша модель данных содержит некоторые сложные иерархические данные , может быть гораздо проще организовать эти данные, используя поднаборы в документах, а не используя вложенные объекты или массивы в одном документе. Например, запрос документов через данные, содержащиеся в массивах, имеет некоторые ограничения .
Опять же, не существует "единой правды": все зависит от вашего конкретного случая c. Обратите внимание, что в мире No SQL ваша модель данных должна быть в основном разработана с учетом запросов, которые вы планируете выполнять, без колебаний денормализуя данные.