英文:
What is the best way to store a (potentially) huge list in Firestore?
问题
我有一个包含许多用户及其详细信息的用户集合。我还有一个通知集合,用户可以在其中查询通知。我预计通知的数量至少会在千级别,但可能会在多年内达到数万级别。
我希望用户能够标记通知为“已查看”。我应该如何处理这个问题?
我考虑了以下选项:
- 在每个用户文档中添加一个名为
notificationsSeen
的数组,其中包含对通知文档的引用。但我担心如果用户已经查看了5万条通知,可能会触及大小限制。 - 同样的方式,将其添加为用户的子集合。但我不太确定如何操作,因为我只真正需要一个属性(通知ID)。我是否将通知ID作为子集合文档ID,并在文档上没有字段?是否让Firestore生成一个随机ID,并将通知ID分配为子集合的属性?
- 在每个通知文档中添加一个名为
seenBy
的数组,其中包含对用户文档的引用。尽管这将允许用户查看其他用户已查看了哪些通知,但我不认为我想要这个。
希望你可以帮我解决这个问题,我已经没有更多的想法,也不确定如何实现我目前为止最好的想法(用户的子集合),这也曾被提及为一个解决方案,但没有提供实施细节。详情请参阅:https://stackoverflow.com/questions/54881751/firestore-storage-size-limit-how-to-store-large-arrays(但没有提供实施细节)。
英文:
I have a users collection with a bunch of users and their details. I also have a notifications collection, that the users can query on. I expect the amount of notifications to be at least in the thousands, but probably tens of thousands over the years.
I want the users to be able to mark a notification as "seen". How would I go about this?
I have considered following options:
- Add an array
notificationsSeen
with references to notification documents to each user document. I'm scared of hitting size limits here though, if a user has seen e.g. 50k notifications. - Add the same but as a sub-collection in users. I'm not sure how to go about this though, since I only really need one property (notification ID). Do I put the notification ID as the sub-collection doc ID and have no fields on the documents? Do I let Firestore generate a random ID and assign the notification ID as a property on the sub-collection?
- Add an array
seenBy
with references to user documents to each notification document. Although this will allow users to see which notifications other users have seen, and I don't think I want this.
Hope you can help me out, I'm out of ideas and I am not sure how to implement the best idea I have so far (sub-collection in users), which has also been mentioned as a solution here: https://stackoverflow.com/questions/54881751/firestore-storage-size-limit-how-to-store-large-arrays (but without implementation details).
答案1
得分: 6
唯一可扩展的方式来存储Firestore中的任意大的数据列表是使用集合中的文档。数组类型字段不适用于不断增长的数据列表,因为项目最终会超过单个文档的1MB大小限制,这显然会在规模上引发问题。
如果一个文档没有字段也是可以的。如果您只需要记录文档的存在以便稍后在该集合中检查其存在,那么这是可以的。您可以使用通知ID作为文档ID,如果您绝对确定该ID符合Firestore中的有效ID。否则,您应该为其分配一个随机ID,并将通知ID作为文档的一个字段,以便以后可以查询它。
您会希望熟悉一下Firestore限制文档上的文档,其中讨论了文档的最大大小以及Firestore文档ID的有效字符。
英文:
The only scalable way to store an arbitrarily large list of data in Firestore is using documents in a collection. Array type fields do not scale for growing lists of data because the items will eventually exceed the 1MB size limit for a single document, which will obviously cause problems at scale.
It's OK to have a document with no fields. If all you need to do is record that a document exists in order to check its existence later in that collection, that's fine. You can use the notification ID as the document ID if you are absolutely certain that ID conforms to valid IDs in Firestore. Otherwise, you should give it a random ID, and also put the notification ID as a field in the document so that you can query for it later.
You will want to familiarize yourself with the documentation on Firestore limits, which talks about the maximum size of a document, and also the valid characters for a Firestore document ID.
答案2
得分: 2
1st option is not possible, as document size limitation defined by firebase, 2nd and 3rd option are possible but 2nd option is a better to implement this feature, and in 2nd option i'll prefer to set notification id as the document id in the subcollection, but setting notification id as property in document is also valid(this option is better suited for case where there are multiple documents with same id, something like posts collection, where user has multiple posts posted).
英文:
1st option is not possible, as document size limitation defined by firebase, 2nd and 3rd option are possible but 2nd option is a better to implement this feature, and in 2nd option i'll prefer to set notification id as the document id in the subcollection, but setting notification id as property in document is also valid(this option is better suited for case where there are multiple documents with same id, something like posts collection, where user has multiple posts posted).
答案3
得分: 0
可以为每个用户建立一个用于存储其通知的集合。在通知被阅读后,可以删除特定用户的文档。您还可以添加一些on_snapshot
目标,以在通知被添加到集合后发送通知。
英文:
It’s possible to build a collection for each user for their notifications. You may delete a user-specific document after the notification is read. You may also add some on_snapshot targets to send out notifications after it’s been added to the collection.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论