База данных Firebase ускоряет простое чтение
Я выполнял профилирование в своей базе данных firebase и обнаружил одну аномалию
Read Speed
┌───────────────────────────────┬───────┬─────────────┬───────────────────┐
│ Path │ Count │ Average │ Permission Denied │
├───────────────────────────────┼───────┼─────────────┼───────────────────┤
│ /safeList │ 4 │ 3,092.50 ms │ 0 │
├───────────────────────────────┼───────┼─────────────┼───────────────────┤
Это означает, что каждый запрос к этой структуре занимал более 3 секунд. Это не самая страшная проблема в мире, но все же странная.
safelist - это список строк, упорядоченных по длине вручную и затем импортированных в firebase. Список содержит около 8000 строк длиной от 5 до 25.
Эти запросы были сделаны мной, и каждый из них запрашивал только первые 5000 образцов из набора.
У меня вопрос:
- Есть ли способ улучшить скорость чтения?
- Если я просто запрошу весь набор вместо первых 5000, будет ли это быстрее?
- Есть предложения по увеличению набора примитивов?
========== ОБНОВЛЕНИЕ ============
Некоторые люди спрашивают о данных и коде.
единственный код, в котором я вызываю этот запрос:
firebase.child("safeList").limitToFirst(5000).addListenerForSingleValueEvent(new ValueEventListener() { //do stuff
я не поставил, потому что это довольно тупо
и как сказано в описании:
Список надежных отправителей - это список строк, содержащий около 8000 элементов, упорядоченных вручную по длине.
относящиеся к нему правила базы данных:
"safeList":{
".read":"root.child('premiums').child(auth.uid).exists()",
".write":false,
".indexOn" : ".value"
},
В среднем требуется 3000 мс, тогда как второй самый медленный запрос занимает всего 60 мс.
Невозможно сказать, что что-то может быть быстрее, не видя точных данных и кода. Посмотрите, сможете ли вы воспроизвести проблему на таком сайте, как jsbin, чтобы мы могли посмотреть (производительность, вероятно, будет примерно одинаковой для Android и JavaScript).
Добавьте код, который вы используете для получения данных из базы данных, и ответьте @.
@FrankvanPuffelen, точными данными невозможно поделиться, а код довольно глупый, как вы можете видеть в моем обновлении
@AlexMamo, я считаю, это потому, что Google требуется больше времени, чтобы уменьшить набор с 8k до 5k
Это все еще довольно расплывчато. Как они упорядочиваются вручную по длине, поскольку Firebase внутренне упорядочивает по ключу. Это пары ключ: значение, где ключ создается с помощью push (), а значение является строкой (в отличие от другой пары ключ: значение). Правила включают индексацию по значению, но запрос не содержит orderByValue. Вы пробовали те же тесты в другой сети, чтобы увидеть, есть ли у вас задержка?
@Jay, ваши комментарии выглядят так, как будто кто-то не знаком с firebase, не все должно быть парой ключ-значение, firebase acepts списки, подобные этому. Сеть не влияет на это измерение, поскольку она получена из инфраструктуры Firebase, поэтому не учитываются задержки сети или клиентов.
Обычно базы данных NoSQL являются хранилищами ключ: значение, а в случае базы данных Firebase все является парой ключ: значение. См. ref1ref2. Когда вы добавляете данные, он становится узлом в структуре со связанным ключом. Список, о котором вы говорите, представляет собой пару «ключ: значение», в которой «список» является значением. Этот вопрос не дает нам достаточно информации, чтобы знать, какова структура этого значения или откуда был получен набор данных, поэтому я спросил. Приношу свои извинения за предположение, что это было через сеть.
считывать данные в пределах, установленных набором, или сделать некоторую службу для чтения данных в фоновом режиме и сохранения их в базе данных