Google 致力于为黑人社区推动种族平等。查看具体举措。

选择数据库：Cloud Firestore 还是实时数据库

Firebase 提供了两种支持实时数据同步且可通过客户端访问的云数据库解决方案：

  • Cloud Firestore 是 Firebase 用于移动应用开发的最新数据库。它具备更直观的新数据模型，在实时数据库的成功基础上更上一层楼。与实时数据库相比，Cloud Firestore 还提供了更丰富、更快速的查询以及更好的扩缩功能。

  • 实时数据库是 Firebase 的原有数据库。对于需要在客户端之间实时同步状态的移动应用，它是一种高效、低延迟的解决方案。

Firebase 推荐哪个数据库？

选择哪种数据库解决方案取决于多种因素，但是，当涉及到具体功能时，我们可以就哪个数据库适合您提出建议。

这两种解决方案都提供以下特性：

  • 客户端优先 SDK，无需部署和维护服务器
  • 实时更新
  • 免费层级，然后按实际用量付费

主要考虑因素

除了两个数据库共同的重要核心功能之外，还要考虑下面列出的任何或所有考虑因素是否影响应用的成功。

数据库的作用
我的应用使用数据库的目的是…
主要是为了通过基本查询同步数据。
如果您不需要高级查询、排序和事务功能，建议您使用实时数据库。
高级查询、排序和事务。
如果您需要与数据进行复杂的互动（例如在电子商务应用中），建议使用 Cloud Firestore。
对数据执行的操作量
我的应用的数据库用量大致为…
经常发生更改的几 GB 或更少的数据。
如果您的应用要发送一连串细微更新（例如在数字白板应用中），建议使用实时数据库。
大小为数百 GB 到 TB，且读取频率比更改频率高得多的数据。
对于非常大的数据集以及经常需要批量操作的情况，建议使用 Cloud Firestore。
数据模型
我希望使用的数据结构为…
简单的 JSON 树。
对于 JSON 非结构化数据，建议使用实时数据库。
文档整理为集合。
对于结构化文档和集合，建议使用 Cloud Firestore。
可用性
我的可用性需求是…
99.999% 的极高正常运行时间保证。
如果可用性至关重要（例如在电子商务应用中），建议使用 Cloud Firestore。
保证正常运行时间至少达到 99.95%。
如果可用性需求很高但并非至关重要，使用 Cloud Firestore 或实时数据库都可以。
对本地数据执行离线查询
我的应用在连接受限或没有连接的设备上执行查询的频率为…
频繁。
如需在用户离线时对本地数据执行复杂查询的功能，建议使用 Cloud Firestore。
极少或从不。
如果您希望用户始终在线，使用 Cloud Firestore 或实时数据库都可以。
数据库实例数
在单个项目中，我需要使用…
许多数据库，例如针对每个主要客户设置一个数据库。
由于您可以将多个数据库添加到单个 Firebase 项目中，因此建议使用实时数据库。
一个数据库。
如果您需要单个数据库，使用 Cloud Firestore 或实时数据库都可以。

还有哪些其他需要注意的重要事项？

在考虑之前的重要考虑因素后，您可能已准备好选择数据库。如果您仍然在权衡利弊，请参阅此部分，详细了解 Cloud Firestore 与实时数据库之间的其他差异。

数据模型

实时数据库和 Cloud Firestore 都是 NoSQL 数据库。

实时数据库 Cloud Firestore
将数据存储为一个大型 JSON 树。
  • 简单数据极易存储。
  • 复杂的分层数据较难大规模组织。

详细了解 Realtime Database 数据模型。

 将数据存储为文档集合。
  • 简单数据很容易存储在文档中，这点与 JSON 非常相似。
  • 通过在文档中使用子集合，复杂的分层数据较易于大规模组织。
  • 反规范化和数据平展方面的需求更少。

了解有关 Cloud Firestore 数据模型的更多信息。

实时和离线支持

两者都具有移动优先的实时 SDK，并且都支持离线就绪应用的本地数据存储。

实时数据库 Cloud Firestore
为 iOS 和 Android 客户端提供离线支持。 为 iOS、Android 和 Web 客户端提供离线支持。

状态

了解客户端处于在线还是离线状态非常有用。Firebase 实时数据库可以记录客户端连接状态，并在客户端连接状态发生变化时提供更新。

实时数据库 Cloud Firestore
支持在线状态检测。 不提供原生支持。您可以使用 Cloud Functions 同步 Cloud Firestore 和实时数据库，从而利用实时数据库对在线状态检测的支持。请参阅在 Cloud Firestore 中构建状态系统。

查询

通过查询从数据库检索、排序和过滤数据。

实时数据库 Cloud Firestore
深度查询，提供有限的排序和过滤功能。
  • 查询可以对属性进行排序或过滤，但两者不能同时进行。
  • 默认情况下进行深入查询：查询始终返回整个子树。
  • 查询可以任何粒度访问数据，粒度可细化到 JSON 树中的各个叶节点值。
  • 查询不需要索引；但是随着数据集的不断增长，某些查询的性能会下降。
 索引式查询，提供复合排序和过滤功能。
  • 在单个查询中，您可以串连多个过滤条件，并对属性同时进行过滤和排序操作。
  • 进行浅层查询：查询只返回特定集合或集合组中的文档，不返回子集合数据。
  • 查询必须始终返回整个文档。
  • 默认情况下查询已编入索引：查询性能与结果集的大小（而不是与数据集的大小）成比例。

写入和事务

实时数据库 Cloud Firestore
基本写入和事务操作。
  • 通过设置和更新操作写入数据。
  • 事务在特定数据子树上属于原子操作。
 高级写入和事务操作。
  • 通过设置和更新操作以及数组和数字运算符等高级转换进行写入数据操作。
  • 事务可以原子方式从数据库的任何部分读取和写入数据。

可靠性和性能

实时数据库 Cloud Firestore
Realtime Database 是一种区域级解决方案。
  • 在区域级配置中可用。在区域中，数据库仅在可用区内可用。
  • 延迟极低，非常适合频繁同步状态的情况。
如需详细了解 Realtime Database 性能和可靠性特性，请参阅服务等级协议。 		Cloud Firestore 是一种可自动扩缩的区域级和多区域解决方案。
  • 将数据放在位于不同区域的多个数据中心，确保全球可扩缩性和高可靠性。
  • 可在全球用于区域配置或多区域配置。
如需详细了解 Cloud Firestore 性能和可靠性特性，请参阅服务等级协议。

可伸缩性

实时数据库 Cloud Firestore
扩容需要进行分片。
  • 在单个数据库中可扩容到约 20 万个并发连接和 1000 次写入/秒。如果超出此范围，需要将数据分片到多个数据库。
  • 对每部分数据的写入速率没有本地限制。
 自动扩容。
  • 完全自动扩容。目前，扩容限制大约是 100 万个并发连接和 1 万次写入/秒。我们计划在未来提高这些限制。
  • 对各个文档或索引的写入速率有限制。

安全

实时数据库 Cloud Firestore
采用将授权与验证分开的级联规则语言。 采用将授权与验证合并的非级联规则。
  • 通过受 Cloud Firestore 安全规则保护的移动 SDK 进行读取和写入。
  • 通过受 Identity and Access Management (IAM) 保护的服务器 SDK 进行读取和写入。
  • 规则不会进行级联，除非您使用通配符。
  • 规则可以限制查询：如果某个查询返回的结果可能包含用户无权访问的数据，则整个查询都会失败。

价格

这两种解决方案都可在 Spark 和 Blaze 定价方案中获得。

实时数据库 Cloud Firestore
仅对带宽和存储收费，但费率较高。

详细了解 Realtime Database 定价方案。

 主要针对在数据库中执行的操作（读取、写入、删除）收费，并以较低的费率对带宽和存储收费。

Cloud Firestore 支持对 App Engine 项目设置每日支出限额，确保不会超出您能接受的费用水平。

详细了解 Cloud Firestore 定价方案。

使用 Cloud Firestore 和实时数据库

您可以在同一个 Firebase 应用或项目中同时使用这两种数据库。这两种 NoSQL 数据库可以存储相同类型的数据，客户端库的工作方式也相似。如果您决定在应用中同时使用这两种数据库，请注意数据库之间的上述差异。

详细了解 Realtime Database 和 Cloud Firestore 提供的功能。

准备好选择数据库了吗？

希望此比较能够帮助您决定采用哪个 Firebase 数据库解决方案。现在，您可以了解如何将数据库添加到 Firebase 项目中。