我正在考虑将Google Cloud Firestore用于多租户应用程序。
我浏览了此页面，该页面提供了有关比例的建议：https://cloud.google.com/firestore/docs/best-practices#designing_for_scale
此页面还显示了限制：https://cloud.google.com/firestore/quotas
我想出了这个解决方案，可以以最小的成本或没有额外的成本来提高应用程序的性能和弹性。
解决方案：我可以在应用程序中的每个多租户集合中使用不同的集合，例如：products_1，orders_1，products_2，orders_2。
我想使用它是因为：
1-它将具有更好的性能，因为我将使用较小的表/索引。否则，从长远来看，它可能包含太多文档。
2-这是可行的，因为代码可以使用名称与集合进行交互，而我不必显式创建集合。与使用关系数据库/ ORM组合进行处理相比，这似乎不是一个大问题。
3-我可以使用不同的名称创建多少个集合没有限制。
所以我的问题是： 我的任何假设是否可能不正确，以致于无法在性能方面获得任何收益，或者即使没有记录，创建无限数量的集合也不可行。
最后，这种方法是否可能造成长期的维护麻烦，而我目前还无法意识到？
谢谢您的时间。
答案 0 :(得分：1)
使用单独的集合分片客户端绝对是提高整体写入吞吐量的一种方法。但是您不需要为集合指定命名约定。
相反，我会考虑为所有租户/用户创建一个顶级集合，然后为每个租户/用户文档创建一个子集合。这样，您为每个租户/用户都有一个单独的子集合，但是仍然具有可预测的集合名称。