Firestore is a serverless document database with all its underlying infrastructure components and complexity hidden from users. Compared to Cloud Bigtable, where we deploy an instance with nodes that define the performance, or Cloud SQL, where we configure CPU, RAM, and storage resources for an instance, there is no node provisioning and resource planning in Firestore. In consequence, Firestore scales horizontally and transparently to a user. Also, the pricing in Firestore is based on consumption (for example, on stored data and operations such as read, write, and delete), not on assigned resources.
Firestore operates in two modes:
- Datastore mode, which is compatible with a Datastore database and can be used by existing Datastore users. It has the same API but a new storage layer that provides strong consistency and high availability. Firestore is a new Datastore version optimized for writes and real-time updates.
- Native mode, which leverages a document model and integrates with third-party clients. It is optimized for concurrent connections.
In both cases, databases can be either multi-regional, with 99.999% SLA, or regional, with 99.99% SLA.
The first step of a Firestore setup is to select the mode. This selection is permanent. In this chapter, we will examine the Native mode. Selecting the location is the second and last step to configure Firestore:
Figure 8.45 – Firestore location options: multi-region and regional
This document database stores collections of organized objects called documents. They consist of named string fields, numbers, and object data values in the form of JSON documents. There is no schema enforcement. Instead, documents are stored in a flexible tree-like structure:
Figure 8.46 – Hierarchical structure of collections and documents
The preceding figure presents a simplified example structure of the Firestore database with collections named Books, Movies, and Music. In every collection, there is a set of documents with fields that describe features of books, films, and albums. Each collection has a subcollection that represents the ratings for some items.
In the following screenshot, we can see how the example Book, Movies, and Music collections could be implemented. For example, the Book collection consists of documents that contain fields describing the details of a book:
Figure 8.47 – The Data view in the Firestore panel with example collections
Firestore has libraries for popular languages such as Java or Python, and Android and iOS devices can access it directly via native SDKs. In most cases, it will be fixed in the code of an application, with an imported Firestore client library to query a database. But we can also use the Google Cloud console to query data. The following example shows a query run against the Book collection, where all the documents containing the defined author name in the author field are listed:
Figure 8.48 – Database query run from the Firestore panel
One of the most valuable features of Firestore that helps developers to build mobile-friendly applications is how it can handle data synchronization between a database and a client in real time: for example, when a user runs a query to see and rate books written by an author and, at the same time, a cover of one of the books changes, a client application is notified, and the changed data is sent to a device. Similarly, data can be synchronized across mobile devices that use the same application.
In addition to real-time updates, Firestore provides offline support. Imagine that a user from the preceding example temporarily loses access to the internet while looking at book ratings in the application. Assuming the application is leveraging the offline support functionality of Firebase, it will cache queries on a mobile device so a user can look at search results, even when a device is offline. Moreover, all the changes made when rating books are queued up on a device and will be uploaded after it goes online:
Figure 8.49 – Real-time updates for online devices and data caching for offline devices
Applications on mobile devices can directly interact with Firestore. Still, usually, there is a logic between a database and users, for example, to moderate uploaded data, send notifications to keep them engaged, or offload some functionality from a mobile application to limit battery usage on devices. Cloud Functions could be used for this purpose.
Looking at the way Firestore is structured, it won’t be a good fit for offline analysis and queries across datasets. But Firestore data can be exported to BigQuery for more advanced queries, and BigQuery will be what we will cover next.