什么时候一起使用 Firebase 实时数据库和 Firestore 才有意义？

Question

在任何情况下，结合使用 realtime 和 firestore 是否有意义？哪些情况更适合 Firebase 实时与 Firestore 或两者的组合？我一直在阅读有关人们遭受巨额成本打击的恐怖故事，无论如何要事先进行测试。

对于上下文，我希望与超过 50,000 种产品的拍卖市场合作。这个想法是能够根据需要过滤这些产品，创建、修改和删除这些产品的出价、最喜欢的项目并检索用户出价。从我读到的关于使用 firebase 的市场的一般建议（以保持低成本）似乎建议将产品存储在实时数据库中，并将用户对象、销售等存储在 firestore 中。我需要的查询类型是找到具有最低/最高出价的产品、最喜欢的项目，以及获取当前用户和购买的用户。

从成本的角度来看，实时存储与 Firestore 何时最佳？

我当前的逻辑是实时存储产品对象，因为它们将被更频繁地引用。或者，我认为将用户信息、他们的出价和购买存储在 Firestore 中的一个文档中是有意义的，因为这只会产生一次读取成本，并且对于高度活跃的用户可能会导致大量数据被传输. 我感到困惑的地方是查看给定产品的先前销售与获取用户先前的销售之类的事情，销售应该实时存储（作为他们自己的对象或嵌入在产品对象中）还是 firestore（嵌入在用户文档中）或两者？

Answer 1

查看您计划制作的应用程序，让我们简短地谈谈它。

一个出价应用程序，首先有人想出售他们的东西，然后他们将其发布到您的应用程序中。然后你的应用程序的每个用户都可能会看到它开始对它出价。现在我不知道您的应用程序将如何工作，但这是我的假设，您将在 firebase 实时数据库中存储投标人的数据和他们的投标。

这将涉及大量的读、写操作。现在 Firestore 确实为您提供20K operations/day，但如果您超过限制，它几乎不会花费您$0.18/100K writes和$0.06/100K reads. 现在，选择完全取决于您的应用程序的规模。如果您的应用程序拥有大量受众，请选择 Realtime-Database。您每月最多可以免费下载 10GB 的数据，除此之外每 GB 一美元。但这有一个问题，如果你坚持 spark 计划，你只能有 100 个同时连接到数据库，所以如果你有大量用户，我怀疑性能。使用 Blaze 计划可以达到 200K，每个数据库也是如此。因此，如果您创建另一个数据库，您将拥有更多。我个人建议根据区域或任何参数创建多个数据库来分散流量。[同样取决于有多少人使用您的应用程序]

在我看来，您应该在您的应用中使用 Firebase 实时数据库。[确保您也使用 Firebase 存储来存储出售物品的大照片]。

最后，当您的操作数量较少但规模较大时，请使用 firestore。当您有许多小任务（例如更新最高出价值或当前为特定事物出价的用户数量）时，请使用 firebase 实时数据库，请使用实时数据库。在我看来，去实时数据库。我也将它用于一些游戏内容，例如存储用户统计信息并随着用户的进展进行更新。这涉及大量读/写/更新/删除操作，所以我坚持使用实时数据库。

何时将 Firestore 与实时数据库一起使用？

正如您提到的用户配置文件，我建议使用 Firestore 来存储这些凭据。因为用户通常不会更新他们的个人资料，所以这不会花费太多写入。此外，投标人对投标更有兴趣，而不是看其他人的资料。因此，即使少数用户检查其他人的个人资料。这不会花费你太多的阅读。但即使您的应用程序的设计方式是投标人必须检查一次卖家的个人资料，那么 firestore 肯定会帮助您减少实时数据库[GB Downloaded]配额的使用。每次有人从您的实时数据库查询数据时，您都会消耗 10 GB 免费下载限制的一部分。

同样正如我提到的同时连接到数据库，如果您在 Firestore 中托管用户配置文件数据，那么 Firestore 将处理配置文件访问，以便投标人从您的应用程序获得更快的响应。只要确保您利用了来自 firebase 存储、firestore 和实时数据库的所有免费配额，并确保您的应用程序的设计方式能够在所有服务之间平均分配流量。在你的后端使用云功能，不要让你的应用程序[.apk] 客户端太重，因为应用程序需要大量代码。所以结论是，使用 firestore 来存储不会被频繁访问的数据，比如用户凭据和他们出售的任何东西。使用实时数据库存储投标数据。哦，是的，如果您还想存储一些统计数据，例如某人购买了多少商品或某些更改过于频繁的信息，请将其放入 firebase 实时数据库中。您可以简单地创建一个子节点users/${username}并将频繁的东西保存在实时数据库中。这不会花费你太多的存储空间，但会占用下载限制。应该不会太贵，尤其是谈论您的应用程序将解决 50000 种产品 XD。

我希望与一个拥有超过 50,000 种产品的拍卖市场合作。

如果您的用户数量相对较少，实时数据库就足够了，但谁知道您的应用程序用户何时会大幅增加。因此，最好将数据同时分布在 Firestore 和实时数据库中，如上所述。

只是一个警告：这就是我所面临的，然后在 stackoverflow 上搜索并找到了这个。即使您只是在 Firestore 中的数据选项卡上滚动，Firestore 也会计算 READS。因此，请确保您不要只是在那里冲浪。我进行了 2 次写入，只是在查看数据的存储方式，而我已经进行了 27 次读取...