随着集合中文档数量的增加和数组中项目的数量的增加，这种搜索会变得非常低效吗？
问题不是事实，即搜索将变得非常低效，而是文档有限制。因此，在文档中可以放入多少数据方面存在一些限制。根据有关使用和限制的官方文档：
文档的最大大小：1 MiB（1,048,576字节）
如您所见，单个文档中的数据总数限制为1 MiB。当我们谈论存储文本时，您可以存储很多，但是随着数组变大，请注意此限制。
如果要在数组中存储大量数据，并且这些数组应该由许多用户更新，则需要注意另一个限制。因此，每个文档每秒只能写入1次。因此，如果您遇到许多用户都试图一次将数据写入/更新到同一文档的情况，那么您可能会开始发现其中一些写入操作会失败。因此，也要注意此限制。
您可能已经注意到，Cloud Firestore中的查询非常快，这是因为Firestore会自动为您文档中的任何字段创建索引。
如果您认为要基于包含集合的特定成员的父项进行查询，请使用maps而不是arrays。
那里有很多帖子说数组在Cloud
Firestore上不能很好地工作，因为当您拥有可以被多个客户端更改的数据时，很容易感到困惑，因为您不知道正在发生什么以及在哪个字段上。如果我使用的是地图，并且用户想要编辑几个不同的字段，甚至是完全相同的字段，我们通常都知道发生了什么。在数组中，情况有所不同。试想一下，如果某个用户想要编辑索引0处的值，而另一些用户想要删除索引0处的值，您将得到截然不同的结果，为什么不这样做，数组越界例外。因此，带有数组的Firestore操作略有不同。因此，您无法在特定索引处执行诸如插入，更新或删除之类的操作。但是如果不
不必担心将元素存储到数组中的确切顺序，那么应该使用数组。Firestore几天前添加了一些功能来添加或删除特定元素，但前提是不关心它们的确切位置。看到这里是官方文档。
结论是，仅当需要将数据一起显示时，才将数据放在同一文档中。另外，不要使它们太大，以至于您需要下载更多实际需要的数据。因此，当您要搜索数据的各个字段或希望数据有增长空间时，请将数据收集起来。如果您要基于该数据搜索父对象，请将数据保留为地图字段。并且如果您获得了通常将其用作标志的项目，请继续使用数组。
