📅  最后修改于: 2021-01-02 03:40:07             🧑  作者: Mango
对于开发任何应用程序(例如桌面,移动和Web),数据库是我们存储数据的前提。在我们可以以每个应用程序可以访问相同数据的方式存储和操作数据的地方,需要进行存储。 Firebase提供Firestore和Firebase实时数据库。这些数据库是基于云的,客户端可访问的数据库解决方案,支持实时数据同步。
Firestore是用于移动应用程序开发的最新数据库。与实时数据库相比,Cloud Firestore具有更丰富的功能,更快的查询并且可以进一步扩展。 Cloud Firestore是一个灵活且可扩展的NoSQL云数据库。它用于存储和同步数据以进行客户端和服务器端开发。它用于Google Cloud Platform和Firebase的移动,Web和服务器开发。
它是Firebase的原始数据库。它是一种低延迟解决方案,对于需要跨客户端实时状态同步的移动应用程序非常有效。 Firebase实时数据库是一个云托管数据库,其中数据以JSON形式存储。数据与每个连接的客户端实时同步。
让我们了解Firestore和实时数据库之间的区别。
对于大多数开发人员来说,建议使用Cloud Firestore数据库来启动新项目。 Cloud Firestore在旨在支持将来版本中更强大功能的基础架构上提供了附加功能,性能和可伸缩性。期望在Cloud Firestore所采用的高级功能中看到更强大的安全规则,新的查询类型以及性能改进。基于以下因素,我们可以比较两种数据库解决方案:
Firestore和Firebase Realtime数据库是NoSQL数据库,这意味着无需创建表和定义架构。
Realtime Database | Cloud Firestore |
---|---|
In the Realtime database, data is stored as one large JSON tree. | In Cloud Firestore, data is stored as a collection of documents. |
The data is simple, so it is very easy to store. | In documents, simple data is very easy to store. Documents are very similar to JSON. |
The complex, hierarchical data is difficult to organize on a large scale. | By using sub-collections, the complex and hierarchical data is easy to organize on a large scale. It requires very less de-normalization and data flattening. |
实时数据库和Firestore支持将本地数据存储到可离线使用的应用程序,并具有实时SDK。
Realtime Database | Cloud Firestore |
---|---|
Offline support for Android and iOS clients. | Offline support for Android and iOS clients. |
联机状态对于了解客户端何时联机或脱机非常有用。每当客户端的连接状态发生更改时,Firebase Realtime Database都会通过记录客户端连接状态来提供更新。
Realtime Database | Cloud Firestore |
---|---|
Realtime database supports presence. | The Firestore doesn’t support presence natively. We can take advantage of the help of real-time databases by syncing Cloud Firestore and Firebase Realtime database using cloud functions. |
通过查询从实时数据库或Cloud Firestore检索,排序和过滤数据。
Realtime Database | Cloud Firestore |
---|---|
It allows us to perform deep queries with limited sorting and filtering functionality. | It allows us to perform indexed queries with compound sorting and filtering. |
The queries can sort or filter on a property, but not for both. | In Cloud Firestore, we can chain filter and combine filtering and sorting on a property in a single query. |
It has deep queries by default, so it always returns the entire subtree. | It has shallow queries, so these queries return documents in a particular collection or collection group. These queries don’t return sub collection data. |
Realtime database queries can access data at any point, down to individual leaf-node values in the JSON tree. | Cloud Firestore queries always return whole documents. |
These queries don’t require an index. But, the performance of certain queries degrades as our dataset grows. | Cloud Firestore queries are indexed by default. The performance of the query is proportional to the size of our result set rather than a dataset. |
Realtime Database | Cloud Firestore |
---|---|
Only basic write and transection operations can perform. | It allows performing advance write and transection operations. |
In real-time, the data is written through set and update operations. | In Cloud Firestore, data is written though set and update operation. With the help of advanced transformations such as array and numeric operators, we can also write data. |
On a specific data subtree, the transactions are atomic. | From any part of the database, the transections can atomically read and write data. |
Realtime Database | Cloud Firestore |
---|---|
It is a single-region solution. | It is a multi-region solution which scales automatically. |
For zonal availability in a single-region, databases are limited. | Protects our data across multiple data centers in different regions, ensuring global scalability and strong reliability. |
Extremely low latency, the ideal option for frequent state-syncing. | Available in either regional or multi-regional configurations around the world. |
Realtime Database | Cloud Firestore |
---|---|
Sharding is required for scaling. | Here, scaling is automatic. |
It scales approximately 200000 concurrent connections, and 1000 writes per second in a single database. Beyond that, it is required to divide the data into multiple databases. | The scaling is done automatically. At present, it can scale up to 1 million concurrent connections, and 10000 writes per second. The limits can be increased in the future. |
For an individual piece of data, there is no local limit on write rates. | It has limits for individual documents or indexes. |
Realtime Database | Cloud Firestore |
---|---|
It uses cascading rules-language, which separates authorization and validation. | It uses no-cascading rules which combine authorization and validation. |
By Realtime database rules, reads and writes from mobile SDKs secured. | With the help of Cloud Firestore security rules, reads and writes from server SDKs secured. |
The read and write rules are a cascade. | The rules are not cascaded unless we use a wildcard. |
The data is validated separately using the validation rule. | The rules can constrain queries. If the result of the query might contain data, the user doesn’t have to access it, then the entire query fails. |
Realtime Database | Cloud Firestore |
---|---|
Charges for bandwidth and storage only, but at a higher rate. | Mainly the operations performed in our database and are charged at a low rate, bandwidth, and storage. |