Практика применения фильтрованных запросов в БД Firestore (.whereField)


#1

Вопрос по фильтрованным запросам типа .whereField именно о практики применения и нагрузке на БД:

  1. Как считаеся фильтрованный запрос? Как один запрос; как количество запросов, равных количеству отфильтрованных элементов; как количество запросов, равных общему количеству элементов, просмотренных в порядке фильтрации?
  2. Второй вопрос вытекает из первого. Что лучше: хранить все коллекции на первом уровне и просто использовать фильтрованные запросы для получения документов по определённому параметру (например задачи каждого юзера хранить в общей коллекции задачи)? Или использовать субколлекции и вытаскивать просто все задачи из субколлекции юзера, например?
  3. Третий вопрос является следствием первых двух:
  • насколько понимаю, фильтрация происходит на стороне сервера и мне как “заказчику ответа” это выгоднее, чем нагружать устройство клиента. Но на сколько этим можно злоупотреблять? ))
  • в своих примерах расчёта стоимости использования БД, Гугл в официальной документации приводит пример “маленького” приложения на 50 000 регистраций и 5 000 активных пользователей в день… Я так понимаю на мой век хватит мощностей Гугл и не стоит переживать из-за нагрузки на сервак? :smile:

Здесь, конечно, мне интересна именно практика тех, кто работает с этой БД и платит за трафик.


#2

Если кому-то интресно:

  1. Остановился на структуре все коллекции в корне (без суб коллекций) с фильтрованными запросами по нужным ключам. Тк фильтрация происходит на строне сервера, то и результат выдачи считается как за один запрос, что выгодно финансово. Ну и плюс нет гемора с удалением суб-коллекций при удалении головной коллеции.
  2. Вылез неожиданный минус: FireStore до сих пор не умеет фильтровать одиночные поля String по типу contains (содержит) - нужно точное совпадение с учётом регистра!.. wtf? Написал в запрос фич - авось добавят :smile: