Общие сведения о выставлении счетов за базу данных в реальном времени

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 и использование данных, проверьте вкладку Usage в консоли Firebase . Вы можете проверить использование за текущий расчетный период, последние 30 дней или последние 24 часа.

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

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

Оптимизировать использование

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

  • Используйте собственные SDK: по возможности используйте SDK, соответствующие платформе вашего приложения, вместо REST API. SDK поддерживают открытые соединения, что снижает затраты на SSL-шифрование, которые обычно добавляются к REST API.
  • Проверьте наличие ошибок: если ваши расходы на пропускную способность неожиданно высоки, убедитесь, что ваше приложение не синхронизирует больше данных или не синхронизируется чаще, чем вы изначально планировали. Чтобы выявить проблемы, используйте инструмент профилирования для измерения операций чтения и включите отладочное ведение журнала в Android , Objective-C и Web SDK. Проверьте фоновые процессы и процессы синхронизации в вашем приложении, чтобы убедиться, что все работает так, как вы планировали.
  • Уменьшите количество подключений: если возможно, попробуйте оптимизировать пропускную способность вашего соединения. Частые, небольшие запросы 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 .