Как структурировать данные приложения лотереи в Firestore? - PullRequest
Новая
       30

Как структурировать данные приложения лотереи в Firestore?

1 голос
/ 28 мая 2019

Я занимаюсь разработкой приложения на реагирующем языке + Cloud Firestore, целью которого является генерирование случайных чисел / билетов для каждого пользователя, заполняющего форму.Эти номера позволят пользователю участвовать в электронной лотерее и бороться за призы рекламной акции.

Эти номера должны быть разделены по сериям, например: 

Series 1 - numbers can range from 0 to 99,999 thousand.
Series 2 - numbers can range from 0 to 99,999 thousand.
Series N - numbers can range from 0 to 99,999 thousand.

Системные требованияявляются:

  • Должны быть сохранены серии и номера, сгенерированные для каждого пользователя (номера, сохраненные для клиента);
  • Каждая акция также должна содержать сгенерированные номера и серии (номера, сгенерированные впромоушен, всего);

В первой структуре в Cloud Firestore мы создали следующую структуру: 

Promotion - Series - Number
(random doc) - 01 - 00131 ...
(random doc) - 01 - 97879 ...
(random doc) - 09 - 99999

Акция - это коллекция, Серия - это суб-рекламная акция-collection, а Number - это подколлекция Series.

Тем не менее, таким образом было сделано много запросов в API Firestore, например, для получения доступных номеров, которые будут сгенерированы в серии, так чтоможет быть сгенерировано новое число.

Другой найденный нами подход состоит в том, что подколлекция чисел может быть массивом сВ коллекции Серии.Это уменьшит количество запросов.

Будет ли числовой массив размером 100 000 превышать максимальный размер документа в 1 МБ?Можно использовать структуру с картой, например, чтобы записать помимо числа другие свойства следующим образом: 

Promotion - Series - Numbers: Map?

1 Ответ

0 голосов
/ 29 мая 2019

«Будет ли массив из 100 000 номеров превышать максимальный размер документа в 1 МБ?»

Каждое число в массиве будет использовать 8 байтов , поэтому только значения массивабудет ~ 800 КБ, тогда с некоторыми дополнительными затратами для имени документа и поля вы все равно должны быть ниже предела.

Однако вам необходимо убедиться, что вы заходите в индексы отдельных полей в пользовательском интерфейсе и создаете исключение для поля массива, поскольку каждое значение массива потребляет 2 записи индекса (а весь массив потребляет 2 самого себя), поэтому вы обязательно превысите 20 000 записей индекса на лимит документа.Примечание. Это означает, что вы не сможете запрашивать массив.

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

Я предполагаю, что эти 2 неписаных предположения:

  1. То же число не может быть дано болеечем один клиент
  2. Большинство, если не все номера в серии будут назначены

Если 2 не верно, вы можете просто сгенерировать число, посмотрите, если оносуществует, и если это так, восстановите и попробуйте снова.Это становится более дорогостоящим, если будет назначено большинство или все номера.

Альтернативой является гибридный подход .

Для 100 000 номеров создайте 1000 документов, которыеиметь по 100 чисел каждое и хранить эти 100 чисел в массиве с именем ticket_number: 

/promotions/<series number>/numbers/<nnnn>
--> ticket_number: [nnnn01, nnnn02, ..., (nnnn+1)00]

В каждом документе есть логическое поле с именем available, для которого установлено значение true, если числа в этом диапазонедо сих пор доступен.Если это не так, удалите поле или установите для него false

Используйте метод , описанный здесь , чтобы выбрать случайный документ из этих документов, где full == true.Из этого документа выберите случайный номер заявки из массива, удалив его и обновив документ.

В конечном итоге все значения будут выбраны таким образом, при этом требуется только чтение и запись одного документа для каждого заявки (кака также запись выбранного числа / серии в отдельный документ).

Замечания по скорости записи

Обратите внимание, что рекомендуется иметь максимальную поддерживаемую скорость записи 1 в секундуза документ.В подходе с одним документом это будет означать либо медленное присвоение номеров, либо некоторый восходящий пакетный механизм.

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

...