Firestore Query/Performance

3
votes

I am new to firestore, I am.confused with the pricing/shallow structure. Would like to know the better way of querying a set of data I have.

I have the data structure as follow:

  • (a) collection [productList ]- main collection

  • (b) document [storeId ]- multiple documents in the range of 100's

  • (c) collection [itemList ]- sub collection

  • (d) document [Items ]- multiple documents in the range of 35 k to 45k

My query will be usually getting data from (d) collection using 'where' clause.

  • would it be better to remove the subcollections and have all it in the (b) documents and keep an extra ref parameter for querying. Keeping like it will increase the (b) document into 100k's of values.

  • does the pricing vary if I change to that data structure,which would be better for pricing and performance.

    • does the pricing(read) depend on the whole set of 100k's or only on the 20 or 30 values returned after the where clause query.
1
firebasenosqlgoogle-cloud-firestore

1 Answers

4
votes

You are only charged for the documents that are returned from a query or get operation, or documents that are skipped when using an offset (see under "managing large result sets"). Your queries are not charged extra for having lots of additional documents in a collection that are unread. But you are charged for that overall storage over time.

If you are trying to minimize your costs, you should minimize both the total number of document reads and overall storage. The database structure that satisfies this may not be the most effective one for your application, however. You may have to trade off between cost for queries, cost of overall storage, speed, and your own convenience. Only you are able to estimate these costs, unless you share the entire contents of your database with someone who can help you make that estimate.