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.
- Проверьте наличие ошибок: если ваши расходы на полосу пропускания неожиданно высоки, убедитесь, что ваше приложение не синхронизирует больше данных или не делает это чаще, чем планировалось. Чтобы выявить проблемы, используйте инструмент профилирования для измерения операций чтения и включите отладочное ведение журнала в Android , Objective-C и Web SDK. Проверьте фоновые процессы и процессы синхронизации в вашем приложении, чтобы убедиться, что всё работает так, как задумано.
- Сократите количество подключений: по возможности оптимизируйте пропускную способность соединения. Частые и небольшие REST-запросы могут быть более затратными, чем одно постоянное соединение с использованием нативного SDK. Если вы используете REST API, рассмотрите возможность использования HTTP-подтверждения активности или событий, отправляемых сервером , что может снизить затраты на SSL-подтверждения.
- Используйте билеты сеанса TLS: сократите накладные расходы на SSL-шифрование при возобновлении соединений, выпустив билеты сеанса TLS . Это особенно полезно, если вам требуются частые и безопасные подключения к базе данных.
- Индексирование запросов: индексация данных сокращает общую пропускную способность, используемую для запросов, что даёт двойное преимущество: снижение затрат и повышение производительности базы данных. Используйте инструмент профилирования для поиска неиндексированных запросов в вашей базе данных.
- Оптимизируйте прослушиватели: добавьте запросы, чтобы ограничить объём данных, возвращаемых операциями прослушивания, и используйте прослушиватели, которые загружают только обновления данных, например,
on()
вместоonce()
. Кроме того, размещайте прослушиватели как можно дальше по пути, чтобы ограничить объём синхронизируемых ими данных. - Сокращение затрат на хранение: периодически выполняйте задания по очистке и удаляйте дублирующиеся данные из базы данных.
- Использование правил: предотвратите любые потенциально дорогостоящие несанкционированные операции с вашей базой данных. Например, использование Firebase Realtime Database Security Rules поможет избежать ситуации, когда злоумышленник многократно загружает всю вашу базу данных. Узнайте больше об использовании правил Firebase Realtime Database Rules .
Оптимальный план оптимизации для вашего приложения зависит от конкретного сценария использования. Хотя это не исчерпывающий список рекомендаций, вы можете найти больше советов и рекомендаций от экспертов Firebase на нашем канале в Slack или на Stack Overflow .