-1

For scalability, minimal reads & writes, and avoid usage limits. This is my approach for a blog-like project, any suggestions for improvements?

enter image description here

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
Mintee
  • 505
  • 4
  • 22
  • We are usually structuring a Firestore database according to the queries that we want to perform. What are those queries? Besides that, [there is no "perfect", "the best" or "the correct" solution for structuring a Cloud Firestore database](https://stackoverflow.com/questions/53053768/what-is-the-correct-way-to-structure-this-kind-of-data-in-firestore). – Alex Mamo Aug 14 '22 at 11:06
  • @AlexMamo That answers my question regarding database structure but I gotta ask, do you get fewer reads & writes if you structure your database with more sub collections/documents like the image above or do you get fewer reads & write with different collections/documents that have fewer sub collections/documents? Also which of the two options can reach usage limits faster? – Mintee Aug 14 '22 at 11:56
  • Reads are based on the number of documents read, regardless of how many collections you have. e.g. if you have two collections with five documents in each and you read them all that that 10 reads. If you have 10 collections with 1 document in each, that's 10 reads as well. Queries are the the same. There's no real way to answer your question because we don't know what kinds of queries you're running and/or how many documents those will return. – Jay Aug 25 '22 at 18:25
  • @Jay What about if I write a document, does it matter how many fields that document have? If I write 1 document with 10 fields, is it the same as writing a document with 1 field ? – Mintee Aug 25 '22 at 20:23
  • @Mintee Correct. The pricing model revolves around *document* reads and writes not around *fields* or *amount of data*; excepting there is a charge for storing said data. So while there's excellent information in the answer by Alex, I am not sure if it's *the* answer of how to structure/improve your database. Can it be improved? Sure. But it may cost more. You could make it more difficult to work with in code as well, which may cost less. So that's what I stated there's no real way to answer the question because it depends on the use case and objective. Lower costs? Easier Code? Both? – Jay Aug 25 '22 at 22:41
  • @Jay I'm still in learning phase, JS and Firebase, so there's a lot of room to improve from now to a real product. But for pricing I'm still unsure how much one GiB is. How many `collections`, `documents`, `fields` or the data stored in fields is one GiB? – Mintee Aug 26 '22 at 18:21
  • Collections documents and fields "do not take up space". The data *within the fields* "take up space". An example, consider one alphanumeric character as 1 byte, Jay = 3 bytes. Frank = 5 bytes etc. If we have a field and a value `name = "Jay"`, that's three bytes. Storing a word processing document, ASCII text only, that's 1000 characters is 1000 bytes. 10 collections with 1 document each with a field `name == "Jay"` is 10 * 1 * 3 bytes = 30 bytes (and 10 reads!). 2 collections with 5 documents each with a field `name == "Jay"` is... 30 bytes (and 10 reads!). *this is an example only* – Jay Aug 26 '22 at 18:53
  • My above comment is purely an example, and an extraordinarily loose explanation of the pricing and may not reflect actual real-world use and will vary wildly depending on use case. See [Firestore Pricing](https://firebase.google.com/docs/firestore/pricing). – Jay Aug 26 '22 at 18:56
  • Thanks I understand bytes and what take up space now, but how many bytes is 1 GiB? Google says over 1 Billion, doesn't seem right. – Mintee Aug 26 '22 at 19:57
  • StackOverflow is not a good place to discuss basic computer fundamentals as it often requires back and forth discussions - this is really a coding specific forum. There are many tutorials and websites devoted to those concepts so that's a great place to get started. Check out the wiki [Gigabyte](https://en.wikipedia.org/wiki/Gigabyte) – Jay Aug 27 '22 at 12:56

1 Answers1

3

It's good to hear that the following structure:

Answers your question, but regarding:

Do I get fewer reads & writes if you structure your database with more sub-collections/documents like the image above?

No, it doesn't really matter if you query a collection or a sub-collection, you'll always have to pay a number of reads that is equal to the number of documents that are returned.

Also which of the two options can reach usage limits faster?

The structure doesn't matter. What it really matters is the number of requests you perform.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • Thanks for the answers! And one last question if I may so I don't have to make a whole post about. Should I reach the maximum number of index entries for a document (40,000), should I then write on a new document or is there another way for this? – Mintee Aug 14 '22 at 12:57
  • When you reach the document limits, no matter what the limits are, you should indeed try to continue with other documents. But it's best to try to avoid reaching the limits. – Alex Mamo Aug 14 '22 at 13:02
  • Avoid in which ways? Be prepared when it reaches amout of % usage and then continue on a new document? – Mintee Aug 14 '22 at 13:10
  • Yes, that's certainly a way of avoiding that, or maybe try using the [Realtime Database](https://firebase.google.com/docs/database) for storing "some" data. There are cases in which the Realtime Database is much cheaper than Firestore. – Alex Mamo Aug 14 '22 at 13:14