На этой странице вы найдете ответы на часто задаваемые вопросы об использовании Firebase Realtime Database и инструкции по устранению неполадок. Если вы не можете найти нужную информацию или вам требуется дополнительная помощь, обратитесь в службу поддержки Firebase.
Что такое одновременное подключение к базе данных?
Одновременное подключение эквивалентно одному мобильному устройству, вкладке браузера или серверному приложению, подключенному к базе данных. Firebase накладывает жесткие ограничения на количество одновременных подключений к базе данных приложения. Эти ограничения действуют для защиты Firebase и наших пользователей от злоупотреблений.
В тарифном плане Spark лимит составляет 100 и не может быть увеличен.
Тарифный план Blaze предусматривает ограничение в 200 000 одновременных подключений на базу данных.
Это ограничение не совпадает с общим количеством пользователей вашего приложения, поскольку они не подключаются все одновременно. Если вам нужно больше 200 000 одновременных подключений, ознакомьтесь с вариантами в статье Масштабирование с несколькими базами данных.
Что делать, если я превысил лимиты на использование Realtime Database?
Если вы получили оповещение по электронной почте или уведомление в консоли Firebase о том, что вы превысили лимиты на использование Realtime Database, вы можете устранить эту проблему в зависимости от того, какой лимит был превышен. Чтобы посмотреть статистику использования Realtime Database, перейдите на панель управления Realtime Database Usage (Использование) в консоли Firebase.
Если вы превысили лимит на скачивание, вы можете перейти на другой тарифный план Firebase или подождать, пока лимит не будет сброшен в начале следующего платежного цикла. Чтобы уменьшить количество скачиваний, выполните следующие действия:
-
Добавьте запросы, чтобы ограничить данные, возвращаемые операциями прослушивания.
-
Проверьте, нет ли неиндексированных запросов.
-
Используйте слушатели, которые скачивают только обновления данных, например
on вместо once.
-
Используйте правила безопасности, чтобы блокировать несанкционированные скачивания.
Если вы превысили лимит на хранение данных, перейдите на другой тарифный план, чтобы избежать перебоев в работе сервисов. Чтобы уменьшить объем данных в базе данных, попробуйте выполнить следующие действия:
- Запустите периодическую очистку.
- Удалите повторяющиеся данные из базы данных.
Изменения в объеме хранилища могут отразиться не сразу.
Если вы превысили лимит на количество одновременных подключений к базе данных, перейдите на другой тарифный план, чтобы избежать перебоев в работе сервиса. Чтобы управлять одновременными подключениями к базе данных, попробуйте подключить пользователей с помощью REST API, если им не требуется подключение в реальном времени.
Что произойдет, если я превышу лимиты на хранение или скачивание данных в Realtime Database, установленные тарифным планом Spark?
Чтобы обеспечить предсказуемую цену, доступные вам ресурсы ограничиваются, когда ваш проект находится на тарифном плане Spark. Это означает, что если вы превысите лимит по плану в течение месяца, ваше приложение будет отключено, чтобы предотвратить дальнейшее использование ресурсов и дополнительные расходы.
Что произойдет, если я превышу лимит на количество одновременных подключений к Realtime Database в тарифном плане Spark?
Если в тарифном плане Spark достигнут лимит одновременных подключений, все последующие подключения будут отклоняться, пока не закроются некоторые из существующих. Приложение продолжит работать для пользователей, которые уже подключены.
Что такое автоматическое резервное копирование? Вы предлагаете ежечасное резервное копирование для Realtime Database?
Автоматическое резервное копирование – это расширенная функция для проектов, использующих тарифный план Blaze. Эта функция создает резервную копию данных Firebase Realtime Database раз в день и загружает ее в Google Cloud Storage.
Резервное копирование каждый час не поддерживается.
Почему в период с сентября 2016 г. по март 2017 г. пропускная способность Realtime Database была ниже средней?
При расчете пропускной способности мы обычно учитываем издержки на шифрование SSL (на основе уровня 5 модели OSI). Однако в сентябре 2016 года мы допустили ошибку, из-за которой в отчетах о пропускной способности не учитывались дополнительные данные, необходимые для шифрования. Это могло привести к искусственному занижению пропускной способности и сумм в счетах за несколько месяцев.
В конце марта 2017 года мы выпустили исправление, которое вернуло отчеты о пропускной способности и выставление счетов к нормальным уровням.
