编辑：此文档结构不好，我在这里有一个后续问题：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
然后，例如，如果我想在今天3:00 PM之后知道用户8993413的所有消息，我可以这样进行：
messages.where("user8293413", "==", true).where("dateTime", ">=", "2019-01-24T15:00:00Z")
从文档中我知道Firestore会为所有字段创建索引， 因此，这意味着它将为user8293413创建特定的索引。 这意味着搜索将很快，对吗？并且将读取次数保持为最少（每条消息读取一次）。
但是，由于我有1000万用户， Firestore必须创建1000万个索引 （假设所有用户都收到消息）。
有问题吗？这么多索引会影响性能吗？所有这些索引的存储成本如何？ Firebase是否已经为大量索引做好了准备？
答案 0 :(得分：0)
但是，由于我有1000万用户，因此Firestore必须创建1000万索引（假设所有用户都收到消息）。
没有办法实现这一目标。根据有关Firestore indexes的官方文档：
数据库的最大组合索引数： 200
如您所见，您的数量限制为200。
有问题吗？这么多索引会影响性能吗？
当然是。由于您不能超过200个限制，因此不会影响性能。如果您将其保持在限制之下，Firestore将保证您的查询将非常快。
所有这些索引的存储成本如何？
这些索引没有成本。
Firebase是否已经为大量索引做好了准备？
不是很大的数字。
要解决此问题，建议您更改结构化数据库的逻辑，因为不允许创建该数量的索引。为此，我建议您为聊天应用程序查看一个可能的database schema，在其中您可以简单地查询聊天消息而无需使用太多索引。