Firebase выставляет счета за данные, которые вы храните в своей базе данных, и за весь исходящий сетевой трафик на уровне сеанса (уровень 5) модели OSI. Плата за хранилище составляет 5 долларов США за каждый ГБ в месяц с ежедневной оценкой. Выставление счетов не зависит от местоположения вашей базы данных. Исходящий трафик включает накладные расходы на соединение и шифрование для всех операций с базой данных и данных, загруженных в ходе чтения базы данных. Как чтение, так и запись базы данных могут привести к увеличению расходов на подключение в вашем счете. Весь трафик в вашу базу данных и из нее, включая операции, запрещенные правилами безопасности, приводит к оплачиваемым расходам.
Вот некоторые распространенные примеры оплачиваемого трафика:
- Загруженные данные. Когда клиенты получают данные из вашей базы данных, Firebase взимает плату за загруженные данные. Как правило, это составляет основную часть ваших затрат на пропускную способность, но это не единственный фактор в вашем счете.
- Накладные расходы протокола: для установления и поддержания сеанса необходим некоторый дополнительный трафик между сервером и клиентами. В зависимости от базового протокола этот трафик может включать: служебные данные протокола Firebase Realtime Database, служебные данные WebSocket и служебные данные заголовка HTTP. Каждый раз, когда устанавливается соединение, эти накладные расходы в сочетании с любыми накладными расходами на шифрование SSL увеличивают стоимость соединения. Несмотря на то, что это не так много пропускной способности для одного запроса, это может быть существенной частью вашего счета, если ваши полезные нагрузки крошечные или вы устанавливаете частые короткие соединения.
- Накладные расходы на шифрование SSL: существуют затраты, связанные с накладными расходами на шифрование SSL, необходимые для безопасных соединений. В среднем эта стоимость составляет примерно 3,5 КБ для начального рукопожатия и примерно десятки байтов для заголовков записей TLS в каждом исходящем сообщении. Для большинства приложений это небольшой процент от вашего счета. Однако это может стать большим процентом, если в вашем конкретном случае требуется много рукопожатий SSL. Например, для устройств, не поддерживающих билеты сеанса TLS , может потребоваться большое количество подтверждений соединения SSL.
- Данные консоли Firebase: хотя обычно это незначительная часть затрат на базу данных реального времени, Firebase взимает плату за данные, которые вы читаете и записываете из консоли Firebase.
Оцените выставленное вам использование
Чтобы увидеть текущие подключения к базе данных в реальном времени и использование данных, перейдите на вкладку «Использование» в консоли 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 или событий, отправленных сервером , которые могут снизить затраты на рукопожатия SSL.
- Используйте билеты сеанса TLS: сократите накладные расходы на шифрование SSL при возобновлении соединений, выпустив билеты сеанса TLS . Это особенно полезно, если вам требуются частые безопасные подключения к базе данных.
- Запросы индексирования. Индексирование данных снижает общую пропускную способность, используемую для запросов, что дает двойное преимущество: снижение затрат и повышение производительности базы данных. Используйте инструмент профилировщика, чтобы найти неиндексированные запросы в вашей базе данных.
- Оптимизируйте свои слушатели: добавьте запросы, чтобы ограничить данные, возвращаемые вашими операциями прослушивания, и используйте прослушиватели, которые загружают только обновления данных — например,
on()
вместоonce()
. Кроме того, размещайте слушателей как можно дальше по пути, чтобы ограничить объем данных, которые они синхронизируют. - Сократите затраты на хранение: периодически выполняйте задания по очистке и уменьшайте дубликаты данных в базе данных.
- Используйте правила: Предотвратите любые потенциально дорогостоящие несанкционированные операции с вашей базой данных. Например, с помощью правил безопасности базы данных Firebase Realtime можно избежать ситуации, когда злоумышленник неоднократно загружает всю вашу базу данных. Узнайте больше об использовании правил базы данных Firebase Realtime .
Лучший план оптимизации для вашего приложения зависит от вашего конкретного варианта использования. Хотя это не исчерпывающий список рекомендаций, вы можете найти дополнительные советы и подсказки от экспертов Firebase на нашем канале Slack или на Stack Overflow .