Firestore generated key versus custom key in a collection?

Question

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!

score 10 · Accepted Answer · answered Jun 25 '18 at 14:39

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.

I cannot accept two answers so I will accept this. Highly appreciate it.Thanks — Asyl Paitesh, Jun 25 '18 at 15:13
please can you explain more on "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." — pariola, Dec 20 '18 at 14:08
here's the link to the new question https://stackoverflow.com/questions/53894789/limitations-of-using-sequential-ids-in-firebase-firestore-rdb — pariola, Dec 22 '18 at 10:19

Alex Mamo · Answer 2 · 2018-06-25T13:56:12.507

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.

Numbers aren't random enough, I guess; not enough entropy, and you can risk two processes to generate the same number key, creating collision. Also you'll soon or later hit the limit of the system (max integer number; 32bit? 64bit? 128..?). Also they are not really numbers as they are interpreted as string. If you need to rely on a sequential order it's better to have a filed containing a timestamp/date; but don't use it as unique identifier. Check the question linked by @pariola in the comments. — Kamafeather, Mar 09 '21 at 20:42

Firestore generated key versus custom key in a collection?

2 Answers2

Linked