Контекст
Моя команда создает виртуальный книжный клуб следующего поколения в реальном времени (не совсем, но это упрощает фактическое использование моего приложения) с Firestore.
Когда пришло времясобравшись в книжном клубе, пользователи присоединятся к своему книжному клубу и проголосуют, какие книги они хотели бы прочитать дальше. Книжные клубы, как правило, имеют от 10 до 15 пользователей, и каждый клуб имеет тенденцию голосовать за 25-30 книг. Каждый пользователь может отдать свой голос за любое количество книг. Эти сеансы голосования в книжном клубе длятся около 3-4 минут и вовлекают всех пользователей клуба, которые проголосовали в этот период времени.
Текущая архитектура Firestore
Моя структура данных выглядит следующим образом:
- bookClubs (коллекция)
- bookClub1 (документ)
- books (сборник)
- book1 (документ)
- book2 (документ)
- ...
- bookX (документ), где X обычно <30 </li>
- пользователей (коллекция)
- user1 (документ))
- user2 (документ)
- ...
- userY (документ), где Y обычно <15 </li>
- bookClub2 (document)
Голоса хранятся в массиве карт в документе книгигде каждая карта содержит uid пользователя, имя и другие метаданные. Каждый из пользователей книжного клуба ожидает изменений, используя snapshotChanges() в документе bookClubX, вместе с коллекцией вложенных книг и коллекцией вложенных пользователей.
Мы делаем это так, чтобы каждый пользовательский клиент мог видеть в реальном времени, какпо каждой книге и каждому ее избирателю отдается большое количество голосов.
Ограничения
В процессе разработки казалось, что с клубами, которые имеют 3-4 пользователя и голосуют 8-12, все идет хорошо. книг. Вчера вечером у нас состоялось первое настоящее собрание настоящих книжных клубов с 15 пользователями и примерно 30-35 книгами, и вещи разбились и сгорели . Устройства перестали отвечать на запросы, мобильные веб-браузеры начали падать, и данные стали синхронизироваться.
После закрытия собрания книжного клуба и необходимости печально голосовать старой бумагой и ручкой наша команда разработчиков вернулась к чертежуСовет, чтобы понять, где что-то могло не получиться.
В документации Firestore мы встретили следующую рекомендуемую лучшую практику:
Сохраняйте скорость документов, которые база данных отправляет отдельному клиенту. до 1 документа / секунду.
В нашем случае каждый пользователь, который присоединяется к документу bookClubZ и звонит snapshotChanges(), должен сбросить документ bookClubZ вместе с каждым документом book иuser документ в двух bookClubZ вложенных коллекциях. Это составляет 1 bookClubZ doc + 30 book docs + 15 user docs = ~ 46 документов, которые читаются при инициализации для каждого клиента пользователя книжного клуба, не говоря уже о каждом обновлении, которое происходит, когда пользователь читаетголосование за книгу.
Мы уже опередили возможности Firestore? Похоже, что мы грубо нарушили рекомендуемую лучшую практику, описанную выше. Этот сценарий лучше подходит для чего-то вроде Socket.io, PubNub, Ably и т. Д.? Является ли наша структура данных Firestore тупой и неэффективной?