Поскольку база данных Firebase получает запросы на чтение и запись, она выполняет их по очереди. Таблица мощностей ввода-вывода базы данных показывает, какой процент времени, в течение которого база данных была занята, выполняла запросы чтения/записи.
Когда эта диаграмма достигает 100%, это означает, что база данных всегда читает или записывает. Вы используете всю емкость ввода-вывода базы данных, доступную вашему приложению. Когда это происходит, любые другие операции помещаются в очередь и вынуждены ждать своей очереди.
Обычно это вызвано записью со многих подключенных устройств или когда некоторые подключенные устройства начинают прослушивать длинные списки данных. Достаточно распространенная причина, когда вы читаете ref.once('value'... из корня базы данных: загрузка всей базы данных занимает некоторое время, которое увеличивается с размером вашей базы данных.
Следует иметь в виду, что, хотя вы можете уменьшить использование полосы пропускания с помощью limitTo...() по запросу, Firebase все равно придется рассматривать все данные в списке и, таким образом, читать все это с диска. Выполнение повторного limitToLast(1).once('value'... в списке сотен тысяч элементов - это надежный способ использовать всю емкость ввода-вывода в базе данных, хотя использование полосы пропускания может быть довольно маленьким.
Очень интересно, спасибо! –
Итак, если у нас есть очень длинный список данных (например, список пользователей в популярном приложении), можем ли мы по-прежнему делать запросы по нему? Я хочу получить только небольшое подмножество, но это значит, что Firebase нужно будет прочитать все профили пользователей. –
Вы можете многое сделать. Но запрос более длинного списка займет больше времени (и, следовательно, использует большую часть емкости ввода-вывода вашей базы данных), чем запрос/доступ к более короткому списку. –