Хранение нескольких токенов устройств в одном документе для запроса из облачной функции

Question

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

В целях экономии я решил создать документы для хранения нескольких пользовательских токенов в одном документе до 1000 пользователей. Я ограничил его до 1000 из-за ограничения размера для одного документа, но я поместил токены устройств пользователей, которые связаны друг с другом, в один и тот же документ, потому что они, вероятно, находятся в одних и тех же группах чата. Я ожидаю огромного уменьшения количества чтений, потому что я могу запросить только один или два документа, чтобы получить все пользовательские токены в большой чат-группе, вместо того, чтобы запрашивать один документ для одного токена. Хотя здесь все звучит хорошо, я не могу избавиться от своих забот. Хотелось бы услышать ваши драгоценные мнения. Это эффективный обходной путь? Какие здесь возможные проблемы?

Answer 1

Хранение нескольких фрагментов содержимого в одном документе - эффективный способ уменьшить количество операций чтения документа. Кажется, вы уже принимаете во внимание некоторые соображения, но вот еще несколько:

• Вы не сможете эффективно запрашивать токены в одном документе, поэтому придется полагаться на другой способ поиска нужных вам документов. Вы уже каким-то образом группируете их, но об этом следует помнить.
• Обычно вы сохраняете каждый токен в нескольких документах. Если вы никогда не делали этого раньше, это может показаться немного неудобным, но это нормально при работе с базами данных № SQL. Однако вы закончили бы несколькими операциями записи для токена: по одной для каждого агрегированного документа, в котором он должен быть.
• Поскольку вы можете читать только полные документы, вы всегда будете читать все токены. Если есть случаи, когда вам понадобится подмножество токенов в ваших агрегированных документах, вы потратите впустую полосу пропускания.
• Вы можете рассмотреть возможность использования базы данных Firebase Realtime для хранения токенов, что не имеет концепции чтения документа, и взимается плата только за хранилище и пропускную способность, используемую токенами (в JSON).