- EDIT：**此文档结构不好，我有一个后续问题：Firestore chat-app: Is this a valid document structure for multi-recipient messages?
假设一个聊天应用程序有1000万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在今天下午3：00之后的所有消息，我可以这样做：
messages.where("user8293413", "==", true).where("dateTime", ">=", "2019-01-24T15:00:00Z")从文档中我知道Firestore会为所有字段创建索引，所以这意味着它会为特定的user8293413创建索引。这意味着搜索速度会很快，对吗？而且读取的次数会保持在最低限度（每条消息读取一次）。
但是，由于我有1000万个用户，Firestore将必须创建1000万个索引（假设所有用户都收到消息）。
这是一个问题吗？那么多的索引会影响性能吗？所有这些索引的存储成本如何？Firebase是否为大量索引做好了准备？
1条答案
按热度按时间amrnrhlw1#
编辑：2022年11月28日
如果您达到了200个索引的限制，您现在可以联系Firebase支持并请求增加索引的数量。请包括所有必要的细节，最重要的是，您需要这些的原因。这不是一个保证，因为您的请求仍然需要工程审查，但值得一试。
但是，由于我有1000万个用户，Firestore将不得不创建1000万个索引（假设所有用户都收到消息）。
没有办法做到这一点。根据官方文件关于Firestore索引：
数据库的最大复合索引数：两百
如您所见，您的上限为200。
有问题吗？那么多索引会影响性能吗？
当然。因为你不能超过200个限制，所以它不会影响性能。如果你保持在限制之下，Firestore保证你的查询将非常快。
所有这些索引的存储成本如何？
索引的唯一成本是存储成本，仅此而已。
Firebase是否为大量索引做好了准备？
这么大的数目不可能。
为了解决这个问题，我建议您更改数据库的结构化逻辑，因为创建这么多的索引是不允许的。为此，我建议您查看一个聊天应用程序的database schema，在其中您可以简单地查询聊天消息，而无需使用这么多的索引。