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

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

Некоторые распространенные примеры оплачиваемого трафика включают в себя:

  • Загруженные данные: когда клиенты получают данные из вашей базы данных, Firebase взимает плату за загруженные данные. Обычно это составляет большую часть затрат на пропускную способность, но это не единственный фактор в вашем счете.
  • Накладные расходы протокола: для установления и поддержания сеанса необходим некоторый дополнительный трафик между сервером и клиентами. В зависимости от базового протокола этот трафик может включать в себя: служебные данные протокола реального времени базы данных Firebase Realtime, служебные данные 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.
  • Проверьте наличие ошибок. Если затраты на пропускную способность неожиданно высоки, убедитесь, что ваше приложение не синхронизирует больше данных или не синхронизирует их чаще, чем вы изначально предполагали. Чтобы выявить проблемы, используйте инструмент профилирования для измерения операций чтения и включите ведение журнала отладки в 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 .

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

,

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

Некоторые распространенные примеры оплачиваемого трафика включают в себя:

  • Загруженные данные: когда клиенты получают данные из вашей базы данных, Firebase взимает плату за загруженные данные. Обычно это составляет большую часть затрат на пропускную способность, но это не единственный фактор в вашем счете.
  • Накладные расходы протокола: для установления и поддержания сеанса необходим некоторый дополнительный трафик между сервером и клиентами. В зависимости от базового протокола этот трафик может включать в себя: служебные данные протокола реального времени базы данных Firebase Realtime, служебные данные 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.
  • Проверьте наличие ошибок. Если затраты на пропускную способность неожиданно высоки, убедитесь, что ваше приложение не синхронизирует больше данных или не синхронизирует их чаще, чем вы изначально предполагали. Чтобы выявить проблемы, используйте инструмент профилирования для измерения операций чтения и включите ведение журнала отладки в 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 .

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

,

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

Некоторые распространенные примеры оплачиваемого трафика включают в себя:

  • Загруженные данные: когда клиенты получают данные из вашей базы данных, Firebase взимает плату за загруженные данные. Обычно это составляет большую часть затрат на пропускную способность, но это не единственный фактор в вашем счете.
  • Накладные расходы протокола: для установления и поддержания сеанса необходим некоторый дополнительный трафик между сервером и клиентами. В зависимости от базового протокола этот трафик может включать в себя: служебные данные протокола реального времени базы данных Firebase Realtime, служебные данные 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.
  • Проверьте наличие ошибок. Если затраты на пропускную способность неожиданно высоки, убедитесь, что ваше приложение не синхронизирует больше данных или не синхронизирует их чаще, чем вы изначально предполагали. Чтобы выявить проблемы, используйте инструмент профилировщика для измерения операций чтения и включите ведение журнала отладки в 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 .

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