谷歌刚刚发布了Cloud Firestore，这是他们针对应用的新文档数据库 .
我一直在阅读文档但我没有看到Firestore和Firebase DB之间存在很多差异 .
重点是Firestore使用的文档和集合与Firebase相比，可以轻松使用查询，Firebase是一个带有JSON基础的传统noSQL数据库 .
我想更多地了解他们的差异或用法，或者Firestore是否刚刚取代Firebase DB？
所以我写了一个关于这个问题的entire blog post，我建议你看一下（或official documentation）以获得更完整的答案 .
但是如果你想要快速（-ish）摘要，这里是：
Better querying and more structured data - 虽然实时数据库只是一个巨大的JSON树，但Cloud Firestore更加结构化 . 您的所有数据都包含文档（基本上是键值存储）和集合（它们是文档集合） . 文档还经常指向子集合，其中包含其他文档，这些文档本身可以包含其他文档，依此类推 .
这种结构化数据可以通过两种方式帮助您 . 首先，所有查询都很浅，这意味着您可以在不抓取下面的所有数据的情况下请求文档 . 这意味着您可以以对您更有意义的方式分层存储数据，而无需担心数据库保持浅薄 . 其次，您有更强大的查询 . 例如，您现在可以跨多个字段进行查询，而无需创建那些组合（和非规范化）数据库其他部分数据的"combo"字段 . 在某些情况下，Cloud Firestore将直接运行这些查询，在其他情况下，它将自动为您创建和维护索引 .
Designed to Scale - Cloud Firestore将能够比实时数据库更好地扩展 . 请务必注意，您的查询会缩放到结果集的大小，而不是数据集 . 因此，无论您的数据集有多大，搜索都将保持快速 .
Easier manual fetching of data - 与实时数据库类似，您可以在Cloud Firestore中设置侦听器以实时流式传输更改 . 但是如果你把内置的主要用例作为主要用例 . （它们比实时数据库中的 once 调用要好得多）
once
Multi region support - 这基本上意味着更高的可靠性，因为您的数据可以同时在多个数据中心之间共享 . 但是您仍然具有很强的一致性，这意味着您始终可以进行查询并确保获得最新版本的数据 .
Different pricing model - 虽然实时数据库主要根据存储或网络带宽收费，但Cloud Firestore主要根据您执行的操作数收费 . 这会更好，还是更糟？这取决于您的应用程序 .
对于为新闻应用程序，回合制多人游戏或类似您自己的Stack Overflow版本提供动力，从定价的角度来看，Cloud Firestore可能看起来非常有利 . 对于像实时组绘图应用程序这样的东西，您可以在多个人之间发送多个更新，它可能比实时数据库更昂贵 .
Why you still might want the to use the Realtime Database - 归结为几个原因 . 1）我之前提到过的整个事情，2）它有更好的延迟，当你需要具有可靠低延迟的东西以获得实时感觉时，实时数据库可能会更好 .
对于大多数新应用，我们建议您查看Cloud Firestore . 但是如果你有一个已经在实时数据库上的应用程序，我不建议仅仅为了切换而进行切换，除非你有令人信服的理由这样做 .
希望有所帮助！
你可以在这里阅读整篇文章：https://medium.com/@beingrahul/firebase-cloud-firestore-v-s-firebase-realtime-database-931d4265d4b0
Firebase Realtime database 被结构化为JSON树，但 Cloud Firestore 是将数据存储在文档（这是一组键值对）和集合（它是文档集合）格式中 .
Firebase Realtime database
Cloud Firestore
More Structure Data
实时数据库将数据存储在JSON树中，但Cloud firestore将数据存储在与JSON非常相似的文档中 .
在Cloud FireStore中，Documents可以包含子集合和嵌套对象（如上图中的“phone”），这两个对象都可以包含字符串等原始字段（如上图中的“name”，“email”等）或复杂对象名单 .
Better Querying
在实时数据库中，我们只能对单个查询中的属性进行排序或过滤，而不能对属性进行排序和过滤 . 而在Cloud FireStore中，您可以链接过滤器并在单个查询中对属性进行过滤和排序组合 .
如果要按降序获取数据，则Cloud fireStore对您非常有用，但对于Realtime数据库，没有可用的查询功能 .
您还可以链接多个“where”方法，以在Cloud FireStore中创建更具体的查询（逻辑AND） .
Scalability
Cloud Firestore会能够比实时数据库更好地扩展 . 请务必注意，您的查询性能与结果集的大小成正比，而不是数据集 . 因此，无论您的数据集有多大，搜索都将保持快速 .
Manual fetching of data
我们可以像Cloud FireStore一样在实时数据库中实时监听数据，但在Cloud FireStore中，我们也可以手动获取数据（如果您只需要一次任何数据） .
Security
在实时数据库中，我们需要使用验证规则单独验证数据，但在Cloud FireStore中，数据验证会自动进行 .
Writing the data
我们可以作为单个批处理执行多个操作，并使用 set() ， update() 或 delete() 方法的任意组合以原子方式完成它们 .
set()
update()
delete()
Pricing
在实时数据库中，仅为带宽和存储充电，但速率更高 . 在Cloud FireStore中，主要针对数据库中执行的操作（读取，写入，删除）以及较低速率的带宽和存储进行收费 .
It is an improved version
Firebase数据库足以满足基本应用程序的需求但它不足以处理复杂的要求 . 这就是Cloud Firestore的推出原因 . 以下是一些重大变化 .
改进了基本文件结构 .
对Web客户端的脱机支持 .
支持更高级的查询 .
写入和事务操作是原子操作 .
可靠性和性能改进
缩放将是自动的 .
会更安全 .
在Cloud Firestore中，即使主要对数据库中执行的操作以及带宽和存储收费，费率也会降低 . 您也可以设置每日支出限额 . Here是有关结算的完整详细信息 .
Future plans of Google
当他们发现实时数据库的缺陷时，他们创建了另一个产品而不是改进旧产品 . 即使没有可靠的细节显示他们目前在实时数据库上的排名，现在是时候开始认为它可能会被放弃 .
Note: On the meantime, also keep in mind that Cloud Firestore is currently in beta.
3 回答
所以我写了一个关于这个问题的entire blog post，我建议你看一下（或official documentation）以获得更完整的答案 .
但是如果你想要快速（-ish）摘要，这里是：
Better querying and more structured data - 虽然实时数据库只是一个巨大的JSON树，但Cloud Firestore更加结构化 . 您的所有数据都包含文档（基本上是键值存储）和集合（它们是文档集合） . 文档还经常指向子集合，其中包含其他文档，这些文档本身可以包含其他文档，依此类推 .
这种结构化数据可以通过两种方式帮助您 . 首先，所有查询都很浅，这意味着您可以在不抓取下面的所有数据的情况下请求文档 . 这意味着您可以以对您更有意义的方式分层存储数据，而无需担心数据库保持浅薄 . 其次，您有更强大的查询 . 例如，您现在可以跨多个字段进行查询，而无需创建那些组合（和非规范化）数据库其他部分数据的"combo"字段 . 在某些情况下，Cloud Firestore将直接运行这些查询，在其他情况下，它将自动为您创建和维护索引 .
Designed to Scale - Cloud Firestore将能够比实时数据库更好地扩展 . 请务必注意，您的查询会缩放到结果集的大小，而不是数据集 . 因此，无论您的数据集有多大，搜索都将保持快速 .
Easier manual fetching of data - 与实时数据库类似，您可以在Cloud Firestore中设置侦听器以实时流式传输更改 . 但是如果你把内置的主要用例作为主要用例 . （它们比实时数据库中的
once调用要好得多）Multi region support - 这基本上意味着更高的可靠性，因为您的数据可以同时在多个数据中心之间共享 . 但是您仍然具有很强的一致性，这意味着您始终可以进行查询并确保获得最新版本的数据 .
Different pricing model - 虽然实时数据库主要根据存储或网络带宽收费，但Cloud Firestore主要根据您执行的操作数收费 . 这会更好，还是更糟？这取决于您的应用程序 .
对于为新闻应用程序，回合制多人游戏或类似您自己的Stack Overflow版本提供动力，从定价的角度来看，Cloud Firestore可能看起来非常有利 . 对于像实时组绘图应用程序这样的东西，您可以在多个人之间发送多个更新，它可能比实时数据库更昂贵 .
Why you still might want the to use the Realtime Database - 归结为几个原因 . 1）我之前提到过的整个事情，2）它有更好的延迟，当你需要具有可靠低延迟的东西以获得实时感觉时，实时数据库可能会更好 .
对于大多数新应用，我们建议您查看Cloud Firestore . 但是如果你有一个已经在实时数据库上的应用程序，我不建议仅仅为了切换而进行切换，除非你有令人信服的理由这样做 .
希望有所帮助！
你可以在这里阅读整篇文章：https://medium.com/@beingrahul/firebase-cloud-firestore-v-s-firebase-realtime-database-931d4265d4b0
Firebase Realtime database被结构化为JSON树，但Cloud Firestore是将数据存储在文档（这是一组键值对）和集合（它是文档集合）格式中 .More Structure Data
实时数据库将数据存储在JSON树中，但Cloud firestore将数据存储在与JSON非常相似的文档中 .
在Cloud FireStore中，Documents可以包含子集合和嵌套对象（如上图中的“phone”），这两个对象都可以包含字符串等原始字段（如上图中的“name”，“email”等）或复杂对象名单 .
Better Querying
在实时数据库中，我们只能对单个查询中的属性进行排序或过滤，而不能对属性进行排序和过滤 . 而在Cloud FireStore中，您可以链接过滤器并在单个查询中对属性进行过滤和排序组合 .
如果要按降序获取数据，则Cloud fireStore对您非常有用，但对于Realtime数据库，没有可用的查询功能 .
您还可以链接多个“where”方法，以在Cloud FireStore中创建更具体的查询（逻辑AND） .
Scalability
Cloud Firestore会能够比实时数据库更好地扩展 . 请务必注意，您的查询性能与结果集的大小成正比，而不是数据集 . 因此，无论您的数据集有多大，搜索都将保持快速 .
Manual fetching of data
我们可以像Cloud FireStore一样在实时数据库中实时监听数据，但在Cloud FireStore中，我们也可以手动获取数据（如果您只需要一次任何数据） .
Security
在实时数据库中，我们需要使用验证规则单独验证数据，但在Cloud FireStore中，数据验证会自动进行 .
Writing the data
我们可以作为单个批处理执行多个操作，并使用
set()，update()或delete()方法的任意组合以原子方式完成它们 .Pricing
在实时数据库中，仅为带宽和存储充电，但速率更高 . 在Cloud FireStore中，主要针对数据库中执行的操作（读取，写入，删除）以及较低速率的带宽和存储进行收费 .
通过实时数据库选择Cloud Firestore的原因
It is an improved version
Firebase数据库足以满足基本应用程序的需求但它不足以处理复杂的要求 . 这就是Cloud Firestore的推出原因 . 以下是一些重大变化 .
改进了基本文件结构 .
对Web客户端的脱机支持 .
支持更高级的查询 .
写入和事务操作是原子操作 .
可靠性和性能改进
缩放将是自动的 .
会更安全 .
Pricing
在Cloud Firestore中，即使主要对数据库中执行的操作以及带宽和存储收费，费率也会降低 . 您也可以设置每日支出限额 . Here是有关结算的完整详细信息 .
Future plans of Google
当他们发现实时数据库的缺陷时，他们创建了另一个产品而不是改进旧产品 . 即使没有可靠的细节显示他们目前在实时数据库上的排名，现在是时候开始认为它可能会被放弃 .
Note: On the meantime, also keep in mind that Cloud Firestore is currently in beta.