Запрос к базе данных Firebase с большим набором данных выполняется очень медленно

#android #database #firebase #firebase-realtime-database #query-performance

#Android #База данных #firebase #firebase-realtime-database #запрос-производительность

Вопрос:

Я использую базу данных Firebase в своем приложении для Android. Обычно это работает нормально. Но когда база данных становится больше, производительность запросов ухудшается. Я добавил около 5 тыс. записей в базу данных (под узлами «elk» и «su»), затем я запросил базу данных (на узлах «cut» и «user»), но все запросы выполняются очень медленно. Я определил индекс данных в правилах базы данных, но это не сработало. Как я могу решить эту проблему?

Вот мои запросы :

 // query to get the zones followed by user
FirebaseDatabase.getInstance()
                .getReference()
                .child("user")
                .child(userID)
                .child("zones");

// query to get cuts on a zone
FirebaseDatabase.getInstance()
                .getReference()
                .child("cut")
                .child(cutType)
                .orderByChild("zoneID")
                .equalTo(zoneID);
  

моя структура базы данных

правила базы данных

Комментарии:

1. Когда вы говорите очень, очень медленно. Насколько медленно вы имеете в виду? У вас есть какие-либо результаты тестов или что-то в этом роде? Как мы можем узнать, что сеть работает нормально или телефон работает нормально, должны быть более конкретные доказательства вашей проблемы, до тех пор мы можем только предполагать и обвинять саму firebase в медленном функционировании. Пожалуйста, попробуйте сгенерировать более конкретные результаты тестов с минимальной, средней, большой базой данных и т.д. Принимая во внимание различные факторы, такие как мощность сети, производительность кэша телефона и т. Д.

2. Вы включили изображение дерева JSON в свой вопрос. Пожалуйста, замените это фактическим JSON в виде текста, который вы можете легко получить, нажав кнопку экспорта в консоли базы данных Firebase. Наличие JSON в виде текста делает его доступным для поиска, позволяет нам легко использовать его для тестирования с вашими фактическими данными и использовать его в нашем ответе, и в целом это просто хорошая вещь.

3. Если что-то происходит медленно, это почти без исключения зависит от пропускной способности вашей сети и загружаемых вами данных. Я не сразу вижу ничего, что кажется необычайно большим, и ваши индексы выглядят корректно для запроса. Если вы можете воспроизвести проблему в jsfiddle / jsbin, мы можем попробовать и посмотреть, как наша производительность сравнивается с вашей.

4. Конечно, я тестировал на разных сетевых подключениях, разных телефонах, минимальных и больших базах данных. Но ничего не изменилось, запрос был очень медленным (это заняло около 4 минут). Я не винил firebase или кого-либо еще. Я просто хотел узнать, что я делаю неправильно. Затем я решил проблему в соответствии с ответом Мэтью Берга. Теперь запрос не медленный, он работает нормально.

Ответ №1:

Если вы хотите продолжить расширение, лучше всего было бы дублировать ваши данные в ссылке на зону, где он знает, какие elk / su являются ее частью. Что-то вроде этого:

 {
    zones: {
        elk: {
            "istan-besik": {                
                "-KSp)bL5....": true,
                ...: true
            }
        }
    }
}
  

Таким образом, когда вы хотите выполнить поиск всего, что вы просто делаете:

 ...child('zones').child(zoneId).child(cutType)
  

А затем перебирайте их, чтобы напрямую получать каждого лося / su

Комментарии:

1. На самом деле, я не хочу продолжать расширение, просто добавляйте новые записи в узлы «elk» и «su».

2. Так что да, расширяя их. Независимо от того, вы должны начать делать это таким образом, чтобы оно оставалось быстрым. Эта методология не использует OrderBy, и это будет очень быстро.

3. Я сделаю, что вы сказали. Но я кое-что не понял: я не использую запрос «OrderBy» для получения зон, за которыми следует пользователь, а узел «user» не находится под узлом «cut», и есть только 2 пользователя, но этот запрос тоже очень медленный. В чем причина этого?

4. Ваш пользовательский запрос выполняется очень медленно?

5. Иногда это работает нормально, но обычно это тоже очень медленно.