I saw on the Firebase Firestore documentation that the limits for the "Maximum depth of subcollections" is 100.
Does this refer to the number of sub-collections that one collection can have in total? Like /collection/document/sub1/document, /collection/document/sub2/document all the way up to /collection/document/sub100/document?
Or does this refer to it in the way that would make the file path longer? For instance: /collection/document/sub1/document/sub2/document/.../sub100/document?
Does this refer to the number of sub-collections that one collection can have in total?
No, it does not refer to the number of sub-collections that one collection can have in total, it refers to the number of subcollections that you can add in-depth, which is up to 100.
Or does this refer to it in the way that would make the file path longer? For instance: /collection/document/sub1/document/sub2/document/.../sub100/document?
Yes, that's the correct approach.
Please also note, that Firestore is as fast as it is at level 1 is also at level 100.
Related
Is there a way to determine a read count for each document in Firestore? I would like to limit read counts to 100,000 per document.
(2022-10-20) Edit:
Starting from now, counting the documents in a collection or the documents that are returned by a query is actually possible without the need for keeping a counter. So you can count the documents using the new [count()][1] method which:
Returns a query that counts the documents in the result set of this query.
This new feature was announced at this year's Firebase summit. Keep in mind that this feature doesn't read the actual documents. So according to the [official documentation][2]:
For aggregation queries such as count(), you are charged one document read for each batch of up to 1000 index entries matched by the query. For aggregation queries that match 0 index entries, there is a minimum charge of one document read.
For example, count() operations that match between 0 and 1000 index entries are billed for one document read. For A count() operation that matches 1500 index entries, you are billed 2 document reads.
Is there a way to determine a read count for each document in Firestore?
As also #FrankvanPuffelen mentioned in his answer, there is no API for doing that. If you need such a mechanism you need to create it yourself. That means that each time a user reads a document, you should increment a counter. That's pretty simple to implement since Firestore provides a really straightforward solution for that. To keep a counter for each read, you can increment a field in a document using ServerValue.increment(1).
Here are the docs for Android:
https://firebase.google.com/docs/database/android/read-and-write#atomic_server-side_increments
Here are the docs for iOS:
https://firebase.google.com/docs/database/ios/read-and-write#atomic_server-side_increments
And here are for the web:
https://firebase.google.com/docs/database/web/read-and-write#atomic_server-side_increments
There is nothing built into Firestore to limit the number of reads for a specific document. There is a quota system (which a.o. is used to enforce the quota on the free plan), but that doesn't apply per document.
You could do this through cloud functions with onRequest or onCall:
Read a value from Realtime database
If the value is larger than 0, return the respective document.
Then decrement the value in Realtime database
Sources:
https://firebase.google.com/docs/database/web/read-and-write#atomic_server-side_increments
https://firebase.google.com/docs/functions/callable
The article about Best practices for Cloud Firestore states that we should keep the rate of write operations for an individual collection under 1,000 operations/second.
But at the same time, the Firebase team says in Choose a data structure that root-level collections "offer the most flexibility and scalability".
What if I have a root-level collection (e.g. "messages") which expects to have more than 1,000 write operations/second?
If you think at that limitation of 1,000 operations/second it's pretty much but if you find your self in a situation in which you need more than that, then you should consider changing your database schema to allow writes on multiple collections. So you should multiply the number of collections. Having a single collection of messages, in which every user can add messages doesn't sound as a good way to go since you can reach that limitation very soon. In this case you should split that collection into multiple other collections. A possible schema might be the one I have explained in the following video:
https://www.youtube.com/watch?v=u3KwKQddPoo
See, at the end of that video, there is collection named messages which in term contains a roomId document. This document contains a subcollection named roomMessages which contains as documents all messages from a chat room. In this case, there are no chances you can reach that limitation.
But at the same time, the Firebase team says in Choose a data structure that root-level collections "offer the most flexibility and scalability".
But also rememeber, Firestore can as quickly look up a collection at level 1 as it can at level 100, so you don't need to worry about that.
The limit of 1,000 ops/sec per collection only apply to realtime update, so as long as you don't have a snapshot listener this should be okay.
I asked the question on the Cloud Firestore Google Groups
The limit is 10,000 writes per second if no other limits apply first:
https://firebase.google.com/docs/firestore/quotas#writes_and_transactions
Also just keep in mind the best practices for scaling cloud firestore
Are collection group query prices the same as a single collection query? Or is there a minimum of one document read per collection even if the query for that collection returns no documents? Is there anything I should watch out for when it comes to billing?
Collections group queries are billed exactly like normal collection queries, as described in the documentation. It stands to reason that if a normal query that returns no documents incurs at least one read, then collection group queries would behave the same way.
There is a minimum of one document-read per query. So if you query across a group of collections and no documents are returned, that will be charged as a single document read.
The easiest way I find to remember this is to think of the read as a change for reading the index. Since a collection group query works from a single index, it is (at least) a single document read for reading that index.
I need to store a large number of fields, like for a star rating system, but firestore only allows 20,000 fields per document. Is there a known way around this? Right now I am going to 'shard' the fields in multiple documents, and keep the size of each document in a documentSizeTracker document that I use to determine which document to shard to (and add to the counter with a transaction). Is this the correct approach? Any problems with this?
Sharding certainly could work. It's hard to say without knowing exactly what kind of data you'll need from your document, and when, but that's certainly a reasonable option. You could also consider having a parent "summary" doc that contains fields you might want to search on and then split all of your data into several documents inside a subcollection of that parent.
One important nuance here: the limit isn't 20,000 fields, but 20,000 indexed fields. So if you're storing a bunch of data inside your document, but you know that you're not going to be searching on all of them, another alternative is to mark some of your fields as unindexed (which you can now do in the Firebase console in the "Exemptions" section).
If you're dealing with thousands of fields, though, you probably won't want to exempt them all one at a time, so a better alternative might be to place your data as a map inside a container field (named something like "allOfMyData"), then just mark that one field as unindexed. That will automatically remove all indexes from any fields contained inside that map.
Actually, I ran into similar problem with the read and write issues with Firebase. So, here is my conclusion:
# if something small needs to be written & read very often, then use Firebase Realtime Database
Firebase Realtime database allows fast writes, but limits concurrent users to 100,000
Firebase Firestore allows a maximum of 1 write per second per document
It's very expensive to read a document that only contains a rating for example in Firestore
# if something (larger) needs to be read very often with writes usually more than 1 second in between then use Firestore
Firestore allows up to 1,000,000 concurrent users at current Beta release (they might make it more)
It's cheaper to read a large document (less than 1 MiB limit) in Firestore than Firebase Realtime database
# If your model doesn't fit into these two choices, then you should modify your model and split them into 2 models:
1 very small model to store in Firebase Real Database (ratings for example)
1 larger model to store in Firestore
Note: You could use both Firebase Realtime database and Firebase Firestore in the same project. Don't forget to take into account the billing differences between both databases. and their different limits. I believe, it's best to combine them and use the good side of each instead of trying to force solutions into one of them.
Note 2: I really didn't like the shard-ing idea in Firestore suggested solution and work around
I am new to firebase firestore and searched, but could not find the limitation for the number of documents that can be handled under one collection. Can anybody help me out to know please.
firebaser here
There is no documented limit to the number of documents that can be stored in a Cloud Firestore collection. The system is designed to scale to huge data sets.
There is no limitation on the number of documents in Firestore collection but it has a limitation of the size of the document.
The maximum size of a document is roughly 1 MiB (1,048,576 bytes).
There are many more limits that are listed in the below link.
Limits of firestore
There is no document limit under one collection
Official documentation for clearness: Click here
But there is limitation in maximum depth of subcollections
there is no limits in documents as #Frank saids, however to answer the question from #Tri, there is a limit of number of sub collections (100) that means collection inside collection