A document world we take a document called the person and we have attributes and on that, we may actually go and embed in and address a contact detail or multiple contact details and this is what the same thing would look like in a JSON document.
Why we need Document Database?
The document database is expressive, efficient, and flexible. Create shallow queries to retrieve data at the document level without needing to retrieve the entire collection or any nested subcollections.
Firestore Document Database
Cloud Firestore is a flexible, scalable database for APP.It keeps your data in sync across client apps through realtime listeners and offers offline support for mobile and web so you can build responsive apps that work regardless of network latency or Internet connectivity. Cloud Firestore also offers seamless integration with other Firebase and Google Cloud Platform products, including Cloud Functions.
How does it work?
Cloud Firestore is a NoSQL database that your apps can access directly via native SDKs. 
Following Cloud Firestore’s NoSQL data model, you store data in documents that contain fields mapping to values. These documents are stored in collections, which are containers for your documents that you can use to organize your data and build queries. Documents support many different data types, from simple strings and numbers, to complex, nested objects. You can also create subcollections within documents and build hierarchical data structures that scale as your database grows. Add, sorting, filtering, and limits to your queries or cursors to paginate your results. To keep data in your apps current, without retrieving your entire database each time an update happens, add realtime listeners. Adding realtime listeners to your app notifies you with a data snapshot whenever the data your client apps are listening to changes, retrieving only the new changes.
Firestore Data Model
Firestore is a document database that means it kind of stores your data in a big tree like structure kind of like the original real-time database but everything is placed into documents and collections.
Documents
You can think of a document is something kind of like a map it’s got key-value pairs which is the Firestone folks like to refer to as fields and the values of these things can be any number of things from strings to numbers to binary values to little small maps that are kind of JSON looking objects. 
Collections
The collection is basically well collections of documents. 
There are a few rules around the use of this thing. Rule 1: Collections can only contain documents nothing else no collections of strings or binary or anything else. Rule 2: Documents can’t contain other documents but they can point to sub collections so it’s very common to see a collection containing a bunch documents which then point to sub-collections that contain other documents and so on in a user workout app for instance. 
I might have a users collection and this collection would contain a document for each user and then each of those documents might point to a workout subcollection that in turn contains a document for each different type of workout that this user is performed and then maybe each one of these has a history sub-collection that keeps track of every time the user performed one of these workouts may be along with like some average heart rate data or some other stuff like that. Rule 3: The root of your database can only consist of the collection now in a normal production app this is going to feel pretty natural. 
Conclusion
If you’re coming from real-time database land this kind of deep nesting might be giving you heart palpitations but don’t worry this kind of data structure is completely normal in the cloud Firestore world where queries are shallow meaning that when you grab data from a document you’ll garb just that document not any of the documents contained in any of the sub-collections below which nice.
Related Post
Firebase Firestore Database for Android Application.