Разница в производительности Firestore через функции Firebase vs Firestore SDK

Question

Наша команда разрабатывает мобильное приложение и в настоящее время использует (Firebase) Firestore для нашего бэкэнда. Мы закрывали каждый доступ к БД с помощью функций Firebase, чтобы очистить объект, возвращенный клиентскому приложению.

Вносит ли этот подход какие-либо (дополнительные) незначительные издержки по сравнению с прямым доступом к Firestore?

Answer 1

Да, но нет в зависимости от вашего варианта использования.

Если у вас небольшое количество пользователей с относительно низким уровнем использования (с точки зрения заданной квоты), рекомендуется применять облачные функции. Как указано в документации , облачная функция Firebase предлагает большую квоту с точки зрения лимитов ресурсов, сроков и лимитов тарифов с хорошей ценой, особенно для плана Spark (БЕСПЛАТНО).

Преимущество в использовании облачных функций заключается в том, что он имеет высокоскоростной и масштабируемый вычислительный / вычислительный блок , который может сократить время обработки определенной функции. по сравнению с использованием процессора мобильного телефона, который в некоторых случаях имеет низкую вычислительную мощность (приходится учитывать разных пользователей, поскольку не каждый обладает телефоном с высокими характеристиками), чтобы обеспечить лучший пользовательский опыт (UX), все эти хлопоты могут быть выполненным функцией Cloud!

Примечание: я согласен с Дагом, когда стоимость является одним из факторов, но мы должны также учитывать производительность и другие перспективы.

Answer 2

Да, но ответ может отличаться в зависимости от ситуации.

Если клиент хочет извлечь запись точно так же, как в базе данных, Firebase SDK может быть быстрее, потому что нет никаких издержек, вызывающих функции Firebase.

Если после извлечения записи у нас будет тяжелая обработка, то Firebase Functions + Firebase Admin SDK может быть быстрее, потому что процессор в Firebase Functions может быть быстрее, чем мобильный ЦП. Однако, если запрос отвечает быстрее, клиентское приложение может отобразить дополнительное сообщение о том, что что-то было выбрано и в данный момент обрабатывается во время интенсивной обработки, взаимодействие с пользователем может быть приемлемым.

Единственный случай, когда я могу придумать функции Firebase, всегда может выиграть, это то, что сервер уменьшает размер данных, так что накладные расходы, представленные функциями Firebase (включая время обработки), были компенсированы более короткой задержкой в ​​сети. Это также имеет преимущество в сохранении тарифного плана клиента.

Answer 3

Да, по крайней мере, теперь ваш путь для получения данных имеет два прыжка вместо одного. Ранее вы обращались к базе данных напрямую, используя канал, оптимизированный для возврата результатов запроса. Теперь вам нужно оплатить стоимость дополнительного перехода к Cloud Functions, который выполняет запрос. И возможно, что результаты, возвращаемые клиенту, будут больше, чем если бы вы сделали запрос напрямую.

Возможно, самая большая потеря, которую вы испытаете, - это кэширование документов на стороне клиента, которое автоматически выполняется клиентом (по умолчанию включено в Android и iOS). Если вы повторяете запрос, и ни один из документов не изменился, вы получаете немедленные результаты из кэша вместо того, чтобы ждать сервера. И вам не придется платить за чтение документов за попадания в кеш. Таким образом, если вы также не кэшируете свои результаты, вы также платите денежную стоимость облачных функций и запроса в Firestore за каждый запрос.