Модель данных из хранилища данных в Firestore

Question

Я пытаюсь перенести несколько плагинов, которые используют DS на FS, и мне было интересно узнать о структуре данных. В моем DS я использую ancestors

, поэтому верхний уровень Kind равен Users, а любой другой Kinds состоит из предков Users. Например. Вид Products имеет предка Key(Users,'UUID').

В Firestore мире, будь это структура, выглядит следующим образом:

1. Users(Collections):
   {userID:...
   ...
   so on},
   {...},
   ...list of users

2. Products(Collections).User-1(Doc)
                           Subcollections{...list of product docs belonging to User1}
                        .User-2(Doc)
                           Subcollections{...list of product docs belonging to User2}

Users и Products коллекции верхнего уровня.

или

эта структура будет лучше:

+ Users (collection)
 * user_1 (document)
     - name: "Blah"
     - last: "Blah"
     + Product (subcollection)
         * product_1 (document)
             - title: "blah...."
             - vendor: "blah..."
             + Product_variants (subcollection)
                 * product_1 (document)
                     - name: "..."
                     - price: "..."
                 * product_2 (document)
                     - name: "..."
                     - price: "..."
         * product_2 (document)
             - title: "blah...."
             - vendor: "blah..."
             + Product_variants (subcollection)
                 * product_1 (document)
                     - name: "..."
                     - price: "..."
                 * product_2 (document)
                     - name: "..."
                     - price: "..."

Есть ли лучший способ справиться с этой структурой? Также беспокойство с точки зрения обновления действия, которое было бы проще? Я пытаюсь понять компромиссы между update против query. Например, если у меня есть пользователи с более чем 1030 * продуктами и получающие события об обновлениях / удалениях / ... есть ли обратная сторона этой структуры.

Answer 1

Обновление: по состоянию на май 2019 года облачное хранилище пожаров теперь поддерживает запросы групп сбора .

Теперь вы можете структурировать данные в любом случае и по-прежнему иметь возможность выполнять запросы по пользователям.

Оригинальный ответ

Если я правильно понимаю, вы спрашиваете о компромиссе между наличием плоских коллекций и подколлекций.

Что касается обновлений, то никаких существенных различий нет. Стоит обратить внимание на наличие полей, которые группируются вокруг одного значения. Например, для плоских коллекций, если у продуктов есть поле времени обновления, по умолчанию вы будете ограничены 500 обновлениями в секунду для всех пользователей. С продуктами, вложенными в пользователей, вы ограничены 500 обновлениями в секунду на пользователя. Однако с помощью плоских коллекций вы можете обойти эту проблему, отключив индекс по умолчанию для одного поля во время обновления и создав составной индекс (пользователь, время обновления). Как только вы это сделаете, это эквивалентно.

Реальная разница сводится к тому, какие запросы возможны. В Firestore, как он существует сегодня, вы можете выполнять запросы только внутри дерева вложенных коллекций. Так, например, если вы хотите искать товары по определенному названию или поставщику, вы сможете выполнять поиск только в пределах одного пользователя.

Если вы сгладите коллекции так, что продукты являются коллекцией верхнего уровня, вы можете делать запросы к пользователям.

Обратите внимание, что запросы группы сбора - это функция, которую мы разрабатываем, которая снимет это ограничение. После запуска вы сможете структурировать данные в любом случае и по-прежнему сможете выполнять запросы между пользователями.