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

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.
• Загрузки: Все байты, загруженные из вашей базы данных, включая протокольные и шифровальные накладные расходы.
• Нагрузка: Этот график показывает, какая часть вашей базы данных используется для обработки запросов за заданный 1-минутный интервал. При приближении загрузки базы данных к 100% могут возникнуть проблемы с производительностью.

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

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

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

Наилучший план оптимизации для вашего приложения зависит от конкретного сценария использования. Хотя это не исчерпывающий список лучших практик, вы можете найти больше советов и рекомендаций от экспертов Firebase на нашем канале Slack или на Stack Overflow .