Cloud Firestore лучшая структура для случая - PullRequest
Новая
       91

Cloud Firestore лучшая структура для случая

0 голосов
/ 20 июня 2020

Я разрабатываю приложение, в котором пользователи (firebase auth) будут регистрировать свои расходы и получать уведомления (OneSignal) каждое воскресенье о расходах, срок действия которых истекает в течение недели. Моя структура firestore: 

-users (collection)
---xxXXxxX (user document)
-----email
-----OneSignal ID
-----expenses (collection)
-------yyYYYyY (expense document)
---------dueDate
---------value
---------userId
-------aaAAaaA (expense document)
---------dueDate
---------value
---------userId
---bBBbbBB (another user document)
-----email
-----OneSignal ID
-----expenses (collection)
-------wwWWwwW (expense document)
---------dueDate
(...)

На основе этой структуры каждое воскресенье Google Cloud будет запускать функцию расписания, которая будет запрашивать все расходы, срок действия которых истекает в течение недели (запрос группы сбора - возвращает список расходов, которые может иметь более одного расхода на пользователя.)

Поскольку этот список все еще функционирует, я вручную отделю userId от расходов, создав второй список с одним регистром для каждого пользователя. Со вторым списком функция получит идентификатор OneSignal для каждого пользователя (еще один запрос в firebase, по одному для каждого пользователя в списке) и зарегистрирует уведомление в службе OneSignal для каждого пользователя.

PS: OneSignal ID может измениться , потому что в этой ситуации я не могу сохранить OneSignalID на расходы.

Я предполагаю, что эта структура будет работать, но похоже, что это не лучшее решение, потому что многие запросы выполняются в «фоновом режиме», и это может быть дорого обойдется в будущем.

Есть ли у кого-нибудь лучшее предложение для этого случая? Может быть, другая структура в firestore ...

Надеюсь, что я хорошо объяснил "проблему". Английский sh не мой родной язык.

Спасибо!

1 Ответ

1 голос
/ 20 июня 2020

Судя по тому, что я читал в документации, у вас все отлично, и вот почему (кто угодно, поправьте меня, если я ошибаюсь)

  1. Firebase заряжает вас, когда пользователи загружают более Xgb данных. Насколько я знаю, вы не будете платить за выполнение запросов и фильтрацию. Итак, вы хороши в этом аспекте.

  2. Время запроса Firebase firestore зависит исключительно от количества получаемых вами результатов. Не имеет значения структура. Так что, если вам нравится эта структура, придерживайтесь ее. Я не вижу никаких проблем.

РЕДАКТИРОВАТЬ: Я просто перечитал документы и обнаружил следующее:

Когда вы используете Cloud Firestore, вы платите для следующего:

  • Количество выполняемых операций чтения, записи и удаления.
  • Объем хранилища, используемого вашей базой данных, включая накладные расходы для метаданных и индексов.
  • Объем используемой пропускной способности сети.

Таким образом, очевидно, что при запросе с вас будет взиматься плата. В этом случае лучшим способом структурирования базы данных было бы, возможно, сглаживание дерева расходов. У вас может быть что-то вроде этого 

Users - - - -
             |------
             |------

Expenses - - - - -
                     user ID - - -
                      Etc---------
                      Etc----------

Таким образом вы можете фильтровать запрос пользователя. https://cloud.google.com/firestore/docs/query-data/queries#: ~: text = Cloud% 20Firestore% 20предоставляет% 20powerful% 20query, Data% 20and% 20Get% 20Realtime% 20Updates .

...