Firestore: хороша ли эта структура документа (с точки зрения скорости и стоимости) для разрешения сообщений с несколькими получателями в приложении чата?

Question

РЕДАКТИРОВАТЬ: Эта структура документа не подходит, и у меня есть следующий вопрос: Firestore chat-app: это допустимая структура документа для сообщений с несколькими получателями?

---

Предположим, что приложение чата имеет 10 миллионов пользователей Firebase и сотни миллионов сообщений.

У меня есть коллекция Firestore, содержащая сообщения, представленные в виде документов во временном ряду, и каждыйиз этих сообщений могут быть получены и просмотрены до 100 из этих пользователей.Обратите внимание, что эти пользователи не организованы в стабильные группы, поскольку каждое сообщение может иметь совершенно разный набор пользователей, которые его получают.

Мне нужно найти очень эффективно (с точки зрения времени и стоимости).), все сообщения через определенное время, направленные определенному пользователю.

Моя Первая попытка будет заключаться в том, чтобы перечислить пользователей-получателей в массиве recipients, например:

"dateTime" : 2019-01-24T20:37:28Z
"recipients" : [user1033029, user9273842, user8293413, user6273581]

Однако это не позволит мне эффективно выполнять свои запросы.

Я думал, что лучшая структура документа, поскольку Firestore не содержит схем, будет делать каждого пользователя полем.Например:

"dateTime" : 2019-01-24T20:37:28Z
"user1033029" : true
"user9273842" : true
"user8293413" : true
"user6273581" : true

Тогда, например, если я хочу узнать все сообщения для пользователя 8293413 после 15:00 сегодня, я мог бы сделать это так:

messages.where("user8293413", "==", true).where("dateTime", ">=", "2019-01-24T15:00:00Z")

Из документации я знаю, что Firestore создаст индексы для всех полей, так что это означает, что он будет создавать индексы для пользователя 8293413 в частности.Это значит, что поиск будет быстрым, верно?И что количество операций чтения будет сведено к минимуму (одно чтение на сообщение).

Однако, поскольку у меня 10 миллионов пользователей, Firestore придется создать 10 миллионов индексов (при условиивсе пользователи получают сообщения).

Это проблема?Повлияет ли так много индексов на производительность?Как насчет стоимости хранения всех этих индексов?Готов ли Firebase к большому количеству индексов?

Answer 1

Однако, поскольку у меня 10 миллионов пользователей, Firestore придется создать 10 миллионов индексов (при условии, что все пользователи получают сообщения).

Нет способа достичь этого.Согласно официальной документации по индексам Firestore :

максимальное количество составных индексов для базы данных: 200

AsВы можете видеть, что вы ограничены 200.

Это проблема?Повлияет ли так много индексов на производительность?

Конечно, есть.Поскольку вы не можете преодолеть ограничение в 200, это не повлияет на производительность.Если вы останетесь ниже этого предела, Firestore гарантирует, что ваши запросы будут очень быстрыми.

Как насчет стоимости хранения всех этих индексов?

Естьникаких затрат для этих индексов.

Готов ли Firebase вообще для большого количества индексов?

Не для такого большого числа.

ToЧтобы решить эту проблему, я рекомендую изменить логику структурирования базы данных, поскольку создание такого количества индексов не допускается.Для этого я рекомендую вам просмотреть возможную схему базы данных для приложения чата, в котором вы можете просто запрашивать сообщения чата без использования стольких индексов.