Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Firestore generated key versus custom key in a collection?

I am using Cloud Firestore database in my Android app and I have different documents within collections like: uid for users, pushed keys for restaurants and numbers for my recipes.

My db:

users
  uid1
  uid2
  ...
resturants
  pushedId1
  pushedId2
  ...
recipes
  0001
  0002
  ...

For the users I understand to use the uid's but is better to use Firestore pushed ids for my restaurants? Is this a convention or why to use it?

I also tried to generate unique keys using UUID Class but is more easy for me to use only numbers for my recipes. Is this a bad approach?

Any help will be appreciated, thank you!

like image 276
Asyl Paitesh Avatar asked Jun 25 '18 13:06

Asyl Paitesh


People also ask

What is the difference between collection and document in firebase?

Documents within the same collection can all contain different fields or store different types of data in those fields. However, it's a good idea to use the same fields and data types across multiple documents, so that you can query the documents more easily. A collection contains documents and nothing else.

How do I find my firestore key?

You can get the ID from the created document by using collection. ref. add(your item without id) and the response (res) will contain the new document reference created with the ID inside it. So get the ID by simply doing res.id.

Is firestore key value store?

In Firestore, you typically have a single collection and multiple documents in that collection. To use Firestore as a key/value store for Workflows, one idea is to use the workflow name as the collection name and use a single document to store all the key/value pairs.

How many documents can a collection hold firestore?

20 for multi-document reads, transactions, and batched writes. The previous limit of 10 also applies to each operation.


2 Answers

By using predictable (e.g. sequential) IDs for documents, you increase the chance you'll hit hotspots in the backend infrastructure. This decreases the scalability of the write operations.

Cloud Firestore has a built-in generator for unique IDs, that is used when you call CollectionReference.add(...) or CollectionReference.document() (without parameters). The ID that it generates is random and highly unpredictable, which prevents hitting certain hotspots in the backend infrastructure.

Using UIDs for the documents of users is a fine substitute for Firestore's built-in generator, since the UIDs already have a high level of entropy: you can't predict the UID of the next user based on knowing the current user. In such a case, using the UID (or otherwise the natural key of the entity) is a better approach, since you can perform direct lookups of the documents instead of having to query.

See this discussion on the firebase-talk mailing list where some of the engineers working on Firestore explain in more detail.

like image 188
Frank van Puffelen Avatar answered Oct 06 '22 11:10

Frank van Puffelen


First of all there are no pushed id's in Firestore. We use the push() method in Firebase Realtime database. In Cloud Firestore we pass no argument to the document() method in order to generate a unique id for a document.

In case of users, the best unique identifier is the uid. In case of other collections like resturants, recipes or any other collection, you should consider using the id's that are generated by Firestore.

Unlike in Firebase Realtime database where there is an astronomically small chance that two users can generate a push ID at the same exact period of time and with the same exact randomness, in Cloud Firestore the IDs are actually purely random (there's no time component included).

And as an answer, you should definitely use the random keys that are generated by Firestore. Don't use simple numbers as keys for your documents.

Edit: Using sequential IDs is an anti-pattern when it comes to Firebase. Is not recommended to use this tehnique in Cloud Firestore nor in Firebase Realtime database, since it will cause scalability problems. To benefit from one of its most important features in Firestore, which is scalability, you should consider not doing this. Scalability is one of Firestore key features and it comes from how Firestore spreads the document out over its storage layer.

Using other tehniques rather than what Firestore offers, increase the hashing collisions, which means you hit write limitations in a shorter time. Having absolut random ids ensures that the writes are spread out evenly across the storage layer.

like image 40
Alex Mamo Avatar answered Oct 06 '22 12:10

Alex Mamo