Я занимаюсь разработкой мобильного приложения в React-Native. Данные хранятся в Cloud Firestore. У меня есть вопрос относительно лучшего способа структурирования данных в Cloud Firestore.
Список контактов, в который каждый пользователь приложения имеет свой мобильный телефон, копируется вдокумент на БД. Данные хранятся в «массиве» в Cloud Firestore. Пример следует.
Например, для пользователь # 1, ниже приведены содержимое документа collection("users").doc("1"):
name: "Suzi",
contacts: [
{userID:"2", name:"John", appMember: false},
{userID:"3", name:"Cathy", appMember: false}
]
Когда один из контактов (Джон или Кэти)регистрируется как пользователь приложения, облачная функция должна проверить, является ли он контактным лицом другого пользователя приложения. Если это так, его / ее контактная запись для этого "пользователя" должна быть обновлена, чтобы показать, что он / она теперь является участником приложения.
Например, если Джон регистрируется как пользователь для приложения, облачная функция обновит приведенный выше документ, чтобы он выглядел следующим образом.
name: "Suzi",
contacts: [
{userID:"2", name:"John", appMember: true}, // <--- appMember changed from false to true
{userID:"3", name:"Cathy", appMember: false}
]
Я понимаю, что НЕ возможно получить доступ / обновить объект Джона {"userID":"2", "name":"John", "appMember": false} напрямую. Единственный способ обновить этот массив - это (1) «получить» весь массив, (2) пройти через него, чтобы найти соответствующий объект, (3) обновить этот объект и (4) сохранить новый обновленный массив обратно в БД,
Можете ли вы придумать лучшую структуру данных для этих данных?
Я думал о сохранении контактов в (1) a "map" контактных объектов (вместо массива контактных объектов) или (2) «подколлекция» контактов. Я думаю, что эти 2 структуры данных более эффективны для обновления объекта конкретного контакта. Следовательно, эти 2 варианта сделают облачные функции более эффективными.
С другой стороны, я думаю, "массивы" (1) намного проще добавить больше контактов и (2) намного проще отображать в пользовательском интерфейсе (используя * 1041)*.) Эти задачи напрямую влияют на опыт пользователей. Итак, я думаю, что эти варианты звучат наиболее подходящими. Хотя облачная функция была бы менее эффективной, влияние на пользователя ощущается меньше (если вообще). Более того, я не думаю, что стоимость выполнения облачных функций имеет какое-либо отношение к количеству «обработанных» данных. Я понимаю, что стоимость в основном зависит от количества полученных документов. Не так ли?
Редактировать (добавить дополнительную информацию об ожидаемых запросах и объеме данных):
1. Ожидаемый объем:
Количество пользователей: 100 000 (но должно масштабироваться до 1 миллиона)
Количество контактов для каждого пользователя: Понятия не имею! Я предполагаю, что большинство людей будет иметь менее 1000 контактов (это размер массива контактов). Чтобы избежать ограничения в 1 МБ для размера документа, я полагаю, что я могу ограничить количество контактов до 10 000. Я думаю, что этого будет достаточно для 99,99% потенциальных пользователей.
2. Ожидаемые запросы:
2.a Обновление Contcats - пользовательский запрос
Частота: несколько раз в день для каждого из 100 000 пользователей
Платформа: пользовательские запросы - НЕ облачные функции
Запрос: список контактов должен быть обновлен. Это включает в себя: (1) получение списка контактов с устройства, (2) сравнение этого списка со списком в БД и (3) внесение некоторых изменений в список, если обнаружены различия. Как уже упоминалось выше, список контактов, вероятно, составляет около 1000 контактов. ПРИМЕЧАНИЕ: было бы гораздо эффективнее, если бы я мог найти способ получать только «изменения» в контактах устройства, а не обрабатывать весь список каждый раз, когда пользователь запрашивает обновление. Однако я НЕ смог найти способ получения изменений (по крайней мере, с помощью React-Native).
2.b Регистрация пользователя - Пользовательский запрос
Частота: 100 - 1000 раз в день
Платформа: пользовательские запросы - НЕ облачные функции
Запрос: всякий раз, когда пользователь регистрируется в приложении, список контактов, который хранится на устройстве, копируется вдБ. Как показано в приведенном выше примере, только 3 или 5 атрибутов (например, UserID, Name, appMember flag) фактически копируются в базу данных. Я должен обслуживать от 100 до 1000 пользователей, которые регистрируются каждый день.
2.c Регистрация пользователя - Облачная функция
Частота: 100 - 1000 раз в день
Платформа: облачные функции - НЕ пользовательские запросы
Запрос: как показано в начале этого вопроса, всякий раз, когда пользователь регистрируется в приложении, облачная функцияНеобходимо проверить, является ли он / она "контакт" для другого пользователя приложения. Если это так, его / ее контактная запись для этого "пользователя" должна быть обновлена, чтобы показать, что он / она теперь является участником приложения. (Пожалуйста, обратитесь к коду в начале этого вопроса)
Ваши усилия и время, чтобы подумать об этом и предоставить свой отзыв, высоко ценится ...