Cloud Firestore和Firebase的区别

速读摘要版区别: 

1.Realtime Database是一个巨大的JSON树,Cloud Firestore更结构化.

2.Cloud Firestore 将能够比Realtime Database更好地扩展.

3.Cloud Firestore可以比Realtime Database更轻松地手动获取数据,因为Cloud Firestore将获取我的数据内置为主要用例,这样会比Realtime Database-land的一次调用更好.

4.多区域支持——这基本上意味着更高的可靠性，因为您的数据一次跨多个数据中心共享。但是您仍然具有很强的一致性，这意味着您始终可以进行查询并确保您获得新版本的数据

完整版原文机翻:

Cloud Firestore——新的数据库，让您可以轻松地将应用程序数据存储和同步到云端，甚至是实时的！

现在，如果您正在经历似曾相识，那么您并不孤单。我们意识到这听起来与您可能已经在使用的另一个产品——Firebase 实时数据库非常相似。因此，如果您正在经历似曾相识，那么您并不孤单。

那么我们为什么要建立另一个数据库呢？你什么时候会选择一个？好吧，让我们谈谈 Cloud Firestore 的新增功能和不同之处，以及您可能希望将其用于下一个应用的原因。

Cloud Firestore 有什么不同？

虽然我们的文档更详细地涵盖了实时数据库和 Cloud Firestore 之间的所有差异，但让我们看看这两种产品之间的主要差异。我们将开始...

更好的查询和更结构化的数据

虽然 Firebase 实时数据库基本上是一个巨大的 JSON 树，任何事情都会发生并且无法无天，但 Cloud Firestore 更加结构化。Cloud Firestore 是一个文档模型数据库，这意味着您的所有数据都存储在称为文档的对象中，这些对象由键值对组成——这些值可以包含任意数量的东西，从字符串到浮点数到二进制数据到 JSON -y 寻找团队喜欢称为maps 的对象。反过来，这些文档被分组到集合中。

您的 Cloud Firestore 数据库可能包含一些包含指向子集合的文档的集合。这些子集合将包含指向其他子集合的文档，依此类推。

这种新结构在查询数据方面为您提供了几个重要的优势。

首先，所有查询都是浅的，这意味着您可以简单地获取文档，而无需获取任何链接子集合中包含的所有数据。这意味着您可以以逻辑上有意义的方式分层存储数据，而不必担心下载大量不必要的数据。

在这个例子中，可以在不抓取下面子集合中的任何文档的情况下获取顶部的文档

其次，Cloud Firestore 具有比实时数据库更强大的查询能力。在实时数据库中，尝试跨多个字段创建查询是一项大量工作，通常涉及对数据进行非规范化。

例如，假设您有一个城市列表，并且想要查找加利福尼亚州人口超过 50 万的所有城市的列表。

城市，存储在实时数据库中

在实时数据库中，您需要通过创建一个明确的“州加人口”字段来执行此搜索，然后运行对该字段排序的查询。

创建组合 state_and_population 字段，仅用于查询

有了 Cloud Firestore，这项工作就不再需要了。在某些情况下，Cloud Firestore 可以自动跨多个字段进行搜索。在其他情况下，例如我们的城市示例，Cloud Firestore 将指导您自动构建使此类查询成为可能所需的索引……

...然后您可以简单地搜索多个字段。

Cloud Firestore 将在您的应用的整个生命周期内自动为您维护此索引。不需要组合字段！

为扩展而设计

虽然实时数据库确实可以扩展以满足许多应用程序的需求，但当您的应用程序变得非常流行，或者您的数据集变得真正庞大时，事情就会开始变得困难。

另一方面，Cloud Firestore 建立在支持一些非常流行的应用程序的相同 Google Cloud 基础架构之上。因此，与实时数据库相比，它将能够更轻松地扩展并扩展到更大的容量。例如，虽然实时数据库高可达 100,000 个并发连接，但 Cloud Firestore 将接受每个数据库多达 1,000,000 个并发客户端连接。如需 Cloud Firestore 限制的完整列表，请务必访问文档。

Cloud Firestore 还拥有比实时数据库更强大的服务级别协议。Cloud Firestore 保证多区域实例的正常运行时间为 99.999%（更多内容见下文）和区域实例的正常运行时间为 99.99%。相比之下，实时数据库保证 99.95% 的正常运行时间。

使用新的查询结构，所有 Cloud Firestore 查询都会根据结果集的大小进行扩展，而不是数据的大小。这意味着，无论您的数据库有 300 家、30 万还是 3000 万家餐厅，搜索芝加哥排名前 10 的餐厅以获取餐厅评论应用所需的时间都是相同的。正如这里的一位工程师喜欢说的那样，“在 Cloud Firstore 中创建慢查询基本上是不可能的。”

更容易手动获取数据

虽然一些开发人员赞赏实时数据库在构建聊天等功能或实现神奇的协作体验方面的实时性，但我们发现，我们的许多开发人员只是想将实时数据库用作传统，“当我要求时，只需获取数据它”的服务。

尽管实时数据库确实通过.once调用支持这一点，但它们有时会觉得使用起来有点不自然，并且经常对 SDK 中的流方法起到次要作用。使用 Cloud Firestore，进行简单的一次性获取查询变得更加自然，并作为 Firestore API 中的主要用例构建。

当然，您仍然可以添加对侦听器的支持，以便您的客户端能够在数据库中的数据更改时接收更新。但是现在您可以灵活地检索数据。

多区域支持可提供更好的可靠性和更多位置

Cloud Firestore 支持多区域位置。这意味着您的数据会一次自动复制到多个地理上不同的区域。因此，如果某些不可预见的灾难导致数据中心——甚至整个区域——离线，您可以放心，您的数据将继续得到服务

对于您的数据库爱好者，我们应该指出 Cloud Firestore 提供强一致性（就像 Cloud Spanner！），这意味着您可以获得多区域支持的好处，同时还知道您将获得新的每当您执行读取时，您的数据的版本。

目前有两个不同的多区域位置可用于托管您的数据（一个在北美，另一个在欧洲）。对于那些不需要多区域数据库的重型功能的人，Cloud Firestore 还在世界各地提供了多个区域实例，其中大部分将从 3 月初开始以较低的价格层提供, 2019。相比之下，实时数据库仅托管在北美。

不同的定价模式

这两个数据库具有完全不同的定价模型：实时数据库主要根据下载的数据量以及您存储在数据库中的数据量来确定成本。

尽管云做的FireStore为这些事情负责，以及，他们显著比你会在实时数据库见降低。相反，Cloud Firestore 的定价主要取决于您执行的读取或写入次数。

这意味着，如果您有一个更传统的移动应用程序，您的客户偶尔会从您的数据库中请求更大的数据块——例如，想想新闻应用程序、约会应用程序或回合制多人游戏之类的东西—— - 您会发现 Cloud Firestore 的定价模型可能比您在实时数据库上运行相同的应用程序更优惠。

另一方面，如果您有一个应用程序，每个客户端每秒进行大量的读取和写入操作（例如，一个群组白板应用程序，您可能每秒多次向其他人广播每个人的绘图更新），Cloud Firestore 可能会更贵。至少对于您的应用程序的那一部分——您始终可以同时使用这两个数据库，这也很好。

当然，这些只是粗略的指导方针，请务必查看我们文档的定价部分，了解有关 Cloud Firestore 定价的所有详细信息。

为什么您可能仍想使用实时数据库

有了这个更改列表，您可能会觉得 Cloud Firestore 比实时数据库更好。虽然 Cloud Firestore 确实对实时数据库进行了大量改进，但在某些情况下，您仍可能需要考虑将实时数据库用于某些数据。具体来说…

• 实时数据库具有对在线状态的本地支持——也就是说，能够判断用户何时上线或下线。虽然我们确实有Cloud Firestore的解决方案，但它并不那么优雅。
• 实时数据库的延迟稍好一些。通常不会太多，但如果您对极低延迟操作有特殊需求，请记住这一点。
• 正如我们上面提到的，Cloud Firestore 的定价模型意味着每个客户端每秒执行大量小读取和写入的应用程序可能比实时数据库中执行类似的应用程序昂贵得多。

告诉我用什么！

一般而言，我们建议新应用程序从 Cloud Firestore 开始，除非您认为您的应用程序具有独特的需求，如我们上面概述的那些，使其更适合实时数据库。

另一方面，如果您有一个已经在实时数据库上运行良好的现有数据库，请继续并保留它！如果您发现自己遇到了 Cloud Firestore 可以真正帮助您解决的问题，那么您可以考虑将部分数据切换或移动到 Cloud Firestore 并同时使用这两个数据库。但不要为了切换而切换。

如果您正在寻找一个神奇的“请将我的数据库从实时数据库转换为 Cloud Firestore”按钮，那么没有！而且，坦率地说，我们不知道是否会有。鉴于两者之间的数据库、查询和定价结构有多么不同，盲目地将针对实时数据库优化的数据库转换到 Cloud Firestore 不一定是一种很好的体验。我们希望您在进行此类更改时更加深思熟虑。