Cloud Firestore和Firebase Realtime Database的区别是什么?

我写了一个关于这个问题的整篇博文，我建议你查看它(或官方文档)以获得更完整的答案。

但如果你想要一个简短的总结，下面是:

更好的查询和更结构化的数据—虽然实时数据库只是一个巨大的JSON树，云Firestore是更结构化的。所有数据都由文档(基本上是键值存储)和集合(是文档的集合)组成。文档还经常指向子集合，子集合包含其他文档，子集合本身可以包含其他文档，等等。

这种结构化数据可以从两个方面帮助您。首先，所有的查询都很肤浅，这意味着你可以请求一个文档而不抓取下面的所有数据。这意味着您可以以一种对您更有意义的方式分层存储数据，而不必担心使数据库保持浅层。其次，您拥有更强大的查询。例如，您现在可以跨多个字段进行查询，而不必创建那些“;组合”;组合(并反规范化)来自数据库其他部分的数据的字段。在某些情况下，Cloud Firestore将直接运行这些查询，在其他情况下，它将自动为您创建和维护索引。

按规模设计—Cloud Firestore将能够比实时数据库更好地扩展。需要注意的是，查询的规模取决于结果集的大小，而不是数据集的大小。因此，无论你的数据集有多大，搜索都将保持快速。

更容易手动获取数据——像Realtime Database一样，你可以在Cloud Firestore中设置监听器来实时输入变化。但如果你不想要这种行为，而只是想要一个简单的“取回我的数据”;调用，云Firestore也有，它是作为一个主要的用例内置的。(它们比Realtime database中的once调用要好得多)

多区域支持——这基本上意味着更高的可靠性，因为你的数据是在多个数据中心共享的。但你仍然有很强的一致性，这意味着你总是可以进行查询，并确保你得到的是最新版本的数据。

不同的定价模式——实时数据库主要根据存储或网络带宽收费，Cloud Firestore主要根据你执行的操作次数收费。这是更好，还是更糟?这取决于你的应用程序。

对于新闻应用、回合制多人游戏或类似Stack Overflow版本的应用来说，Cloud Firestore从定价角度来看是非常有利的。对于像实时群组绘图应用程序，你需要在一秒钟内向多人发送多个更新，这可能比实时数据库更昂贵。

为什么你仍然想要使用实时数据库——这可以归结为几个原因。

1. 总的来说，对于频繁更新的应用程序来说可能会更便宜;我之前提到的

2. 它已经存在了很长一段时间，已经被成千上万的应用程序测试过了，

3. 它有更好的延迟，当你需要可靠的低延迟来获得实时性时，实时数据库可能会更好。

对于大多数新的应用程序，我们建议你检查云Firestore。但如果你的应用已经在实时数据库中了，我不建议你只是为了切换而切换，除非你有令人信服的理由这么做。

选择Cloud Firestore而不是Realtime Database的原因

这是一个改进版本

Firebase数据库足以满足基本应用程序的需求。但是它还不够强大，无法处理复杂的需求。这就是引入Cloud Firestore的原因。以下是一些主要的变化。

• 改进了基本文件结构。
• 对web客户端的离线支持。
• 支持更高级的查询。
• 写操作和事务操作是原子的。
• 可靠性和性能改进
• 缩放将是自动的。
• 会更安全。

定价

在Cloud Firestore中，尽管它主要是对在数据库中执行的操作以及带宽和存储进行收费，但费率已经降低了。你也可以设定每天的消费限额。在这里是关于计费的完整细节。

谷歌的未来计划

当他们发现实时数据库的缺陷时，他们创建了另一个产品，而不是改进旧的产品。尽管没有可靠的细节显示他们目前在实时数据库中的地位，但现在是时候开始考虑它可能会被放弃了。

摘自谷歌文档，这里有一个小总结:

FireBase Real Time DB是基于JSON的NO SQL DB，适用于移动应用程序，区域性，通常用于实时/极低延迟地在用户/设备之间存储和同步数据。

FireStore是JSON“像”NOSQL DB意味着高并发性，全局，易于自动扩展持久性，为任何客户端(不仅仅是移动应用程序)设计的典型用例，如资产跟踪，实时分析，构建零售产品目录，社交用户配置文件，游戏排行榜，聊天应用程序等。

• Cloud Firestore是Firebase的移动应用程序数据库 发展。它建立在实时数据库的成功基础上 一个新的、更直观的数据模型。Cloud Firestore也有功能

• Realtime Database是Firebase的原始数据库。这是一个有效的， 需要同步状态的移动应用程序的低延迟解决方案
. .