Firestore сгенерированный ключ против пользовательского ключа в коллекции?

Question

Я использую базу данных Cloud Firestore в своем приложении для Android, и у меня есть разные документы в коллекциях, такие как: uid для пользователей, нажатые клавиши для ресторанов и номера для моих рецептов.

My db:

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

Для пользователей, которые, как я понимаю, используют uid, но лучше ли использовать push-идентификаторы Firestore для моих ресторанов?Это соглашение или зачем его использовать?

Я также пытался генерировать уникальные ключи, используя UUID Class , но мне проще использовать только числа для моих рецептов.Это плохой подход?

Любая помощь будет оценена, спасибо!

Answer 1

Используя предсказуемые (например, последовательные) идентификаторы для документов, вы увеличиваете вероятность попадания в горячие точки в серверной инфраструктуре.Это уменьшает масштабируемость операций write .

Cloud Firestore имеет встроенный генератор уникальных идентификаторов, который используется при вызове CollectionReference.add(...) или CollectionReference.document() (без параметров).Генерируемый ими идентификатор является случайным и крайне непредсказуемым, что предотвращает попадание в определенные горячие точки в серверной инфраструктуре.

Использование идентификаторов UID для документов пользователей является прекрасной заменой встроенного генератора Firestore, поскольку идентификаторы UID уже имеют высокий уровень энтропии: вы не можете предсказать UID следующего пользователя, основываясь на знаниитекущий пользователь.В таком случае лучше использовать UID (или иным образом естественный ключ объекта), поскольку вы можете выполнять прямой поиск документов вместо необходимости запрашивать.

См. Это обсуждение в списке рассылки firebase-talk , где некоторые инженеры, работающие над Firestore, объясняют более подробно.

Answer 2

Прежде всего, в Firestore нет выдвинутых идентификаторов.Мы используем метод push () в базе данных Firebase Realtime.В Cloud Firestore мы передаем без аргумента методу document(), чтобы сгенерировать уникальный идентификатор для документа.

В случае пользователей лучшим уникальным идентификатором является uid,В случае других коллекций, таких как resturants, recipes или любой другой коллекции, вам следует рассмотреть возможность использования идентификаторов, сгенерированных Firestore.

В отличие от базы данных Firebase Realtime, где существует астрономически малая вероятность того, что двапользователи могут генерировать push-идентификаторы в один и тот же точный промежуток времени и с той же точной случайностью, в Cloud Firestore идентификаторы фактически являются чисто случайными (без учета временного компонента).

И как ответ, вы должныобязательно используйте случайные ключи, сгенерированные Firestore.Не используйте простые числа в качестве ключей для ваших документов.

Редактировать: Использование последовательных идентификаторов является анти-паттерном, когда дело доходит до Firebase.Не рекомендуется использовать эту технику ни в Cloud Firestore, ни в базе данных Firebase Realtime, поскольку это вызовет проблемы с масштабируемостью.Чтобы воспользоваться одной из наиболее важных функций Firestore, а именно масштабируемостью, вам следует подумать об этом.Масштабируемость является одной из ключевых функций Firestore, и она проистекает из того, как Firestore распределяет документ по слою хранения.

Использование других методов, а не тех, которые предлагает Firestore, увеличивает коллизии хеширования, что означает, что вы сталкиваетесь с ограничениями записи вкороче времяАбсолютные случайные идентификаторы обеспечивают равномерное распределение записей по всему уровню хранилища.