Оплата Realtime Database

Если в вашем проекте используется бесплатный тарифный план Spark, то плата за использование Realtime Database не взимается. Вы получаете бесплатное использование, которое включает 1 ГБ хранилища данных и 10 ГБ скачивания данных в месяц.

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

Далее в статье приведено более подробное описание оплаты.

Как Realtime Database рассчитывает оплату

Firebase взимает плату за данные, которые вы храните в базе данных, и за весь исходящий сетевой трафик на сеансовом уровне (уровень 5) модели OSI. Стоимость хранилища составляет 5 долларов США за каждый ГБ в месяц. Расчет выполняется ежедневно. Местоположение базы данных не влияет на оплату. Исходящий трафик включает в себя накладные расходы на подключение и шифрование для всех операций с базой данных и данных, скачанных в результате чтения базы данных. Как чтение, так и запись в базу данных могут привести к расходам на подключение, которые будут отражены в вашем счете. Весь трафик, поступающий в базу данных и исходящий из нее, включая операции, запрещенные правилами безопасности, оплачивается.

Вот несколько примеров оплачиваемого трафика:

  • Скачивание данных. Когда клиенты получают данные из вашей базы данных, Firebase взимает плату за скачивание данных. Обычно это составляет основную часть ваших расходов на пропускную способность, но это не единственный фактор в вашем счете.
  • Избыточность протокола. Для установления и поддержания сеанса требуется дополнительный трафик между сервером и клиентами. В зависимости от используемого протокола этот трафик может включать в себя: избыточные данные протокола реального времени Firebase Realtime Database, избыточные данные WebSocket и избыточные данные заголовка HTTP. Каждый раз, когда устанавливается соединение, эти накладные расходы, а также расходы на SSL-шифрование, увеличивают стоимость соединения. Хотя это не так много для одного запроса, это может быть существенной частью вашего счета, если ваши полезные нагрузки крошечные или вы часто устанавливаете короткие соединения.
  • Дополнительные расходы на шифрование SSL. Для обеспечения безопасного соединения требуется шифрование SSL, которое связано с дополнительными расходами. В среднем это около 3,5 КБ для первоначального рукопожатия и примерно десятки байтов для заголовков записей TLS в каждом исходящем сообщении. Для большинства приложений это небольшая часть счета. Однако если в вашем случае требуется много рукопожатий SSL, то эта доля может быть значительной. Например, устройства, которые не поддерживают билеты сеансов TLS, могут требовать большого количества подтверждений SSL-подключения.
  • Данные консоли Firebase. Обычно это незначительная часть расходов на Realtime Database, но Firebase взимает плату за данные, которые вы считываете и записываете в консоли Firebase.

Как оценить объем использования, за который взимается плата

Чтобы посмотреть текущие подключения Realtime Database и использование данных, откройте вкладку Использование в консоли Firebase. Вы можете посмотреть данные за текущий расчетный период, последние 30 дней или последние 24 часа.

Firebase показывает статистику использования для следующих показателей:

  • Подключения. Количество одновременных открытых подключений к базе данных в реальном времени. К ним относятся следующие подключения в реальном времени: WebSocket, длинный опрос и события, отправленные сервером HTML. Запросы RESTful не учитываются.
  • Хранилище. Объем данных, хранящихся в базе данных. Это не относится к хостингу Firebase и данным, хранящимся в других продуктах Firebase.
  • Скачивания. Все байты, скачанные из базы данных, включая накладные расходы на протокол и шифрование.
  • Нагрузка. На этом графике показано, какая часть базы данных используется для обработки запросов в течение заданного одноминутного интервала. Вы можете столкнуться с проблемами производительности, когда ваша база данных приблизится к 100%.

Оптимизация использования

Чтобы оптимизировать использование базы данных и расходы на трафик, следуйте рекомендациям ниже.

  • Используйте нативные SDK. По возможности используйте SDK, соответствующие платформе вашего приложения, а не REST API. SDK поддерживают открытые подключения, снижая затраты на SSL-шифрование, которые обычно увеличиваются при использовании REST API.
  • Проверьте, нет ли ошибок. Если расходы на пропускную способность неожиданно высоки, убедитесь, что приложение не синхронизирует больше данных или не делает это чаще, чем вы планировали. Чтобы выявить проблемы, используйте инструмент профилирования для измерения операций чтения и включите ведение журнала отладки в SDK для Android, Objective-C и веб-приложений. Проверьте фоновые процессы и процессы синхронизации в приложении, чтобы убедиться, что все работает правильно.
  • Уменьшите количество подключений. По возможности оптимизируйте пропускную способность подключения. Частые небольшие REST-запросы могут быть более затратными, чем одно непрерывное подключение с использованием нативного SDK. Если вы используете REST API, рекомендуем использовать HTTP keep-alive или события, отправляемые сервером. Это позволит снизить расходы на SSL-рукопожатия.
  • Используйте билеты сеансов TLS. Чтобы снизить накладные расходы на шифрование SSL при возобновлении подключений, выпускайте билеты сеансов TLS. Это особенно полезно, если вам требуется частое и безопасное подключение к базе данных.
  • Индексируйте запросы. Индексирование данных снижает общую пропускную способность, используемую для запросов, что позволяет сократить расходы и повысить производительность базы данных. Используйте инструмент профилирования, чтобы найти неиндексированные запросы в базе данных.
  • Оптимизируйте прослушиватели. Добавьте запросы, чтобы ограничить объем данных, возвращаемых операциями прослушивания, и используйте прослушиватели, которые скачивают только обновления данных, например on() вместо once(). Кроме того, размещайте прослушиватели как можно дальше по пути, чтобы ограничить объем синхронизируемых данных.
  • Снижение расходов на хранение. Периодически выполняйте задания по очистке и сокращайте дублирующиеся данные в базе данных.
  • Используйте правила. Предотвращайте любые потенциально дорогостоящие несанкционированные операции с вашей базой данных. Например, использование Firebase Realtime Database Security Rules может предотвратить сценарий, в котором злоумышленник неоднократно загружает всю вашу базу данных. Подробнее об использовании правил Firebase Realtime Database…

План оптимизации зависит от конкретного случая. Это не полный список рекомендаций. Вы можете найти больше советов и подсказок от экспертов Firebase на нашем канале Slack или на Stack Overflow.