Каков наилучший способ хранения (потенциально) огромного списка в Firestore?

Question

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

Я хочу, чтобы пользователи могли пометить уведомление как «увиденное». Как бы я go об этом?

Я рассмотрел следующие варианты:

• Добавить массив notificationsSeen со ссылками на документы уведомлений для каждого пользовательского документа. Однако я боюсь превышать ограничения по размеру, если пользователь видел, например, 50 000 уведомлений.
• Добавьте то же самое, но в качестве вспомогательной коллекции для пользователей. Я не уверен, как go об этом, так как мне действительно нужно только одно свойство (идентификатор уведомления). Нужно ли указывать идентификатор уведомления в качестве идентификатора подсекции с идентификатором c, и в документах нет полей? Позволить ли Firestore генерировать случайный идентификатор и назначать идентификатор уведомления в качестве свойства для подсборки?
• Добавить массив seenBy со ссылками на пользовательские документы для каждого документа уведомления. Хотя это позволит пользователям видеть, какие уведомления видели другие пользователи, и я не думаю, что хочу этого.

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

Answer 1

Масштабируемый способ * для хранения произвольно большого списка данных в Firestore - использование документов в коллекции. Поля типа массива не масштабируются для растущих списков данных, потому что элементы в конечном итоге превысят ограничение размера 1 МБ для одного документа, что, очевидно, вызовет проблемы при масштабировании.

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

Возможно, вы захотите ознакомиться с документацией по Firestore ограничивает , что говорит о максимальном размере документа, а также допустимых символах для идентификатора документа Firestore.

Answer 2

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

Answer 3

Можно создать коллекцию для каждого пользователя для своих уведомлений. Вы можете удалить пользовательский c документ после прочтения уведомления. Вы также можете добавить несколько целей on_snapshot для отправки уведомлений после их добавления в коллекцию.