Предположим, мы хотим получить 15 случайных дочерних элементов из узла questions
со структурой этой базы данных, как показано ниже:
1. Первый (интуитивный и обсуждаемый) способ извлечения случайных дочерних элементов из Firebase — получить весь требуемый родительский узел (questions
как dataSnapshot), а затем выбрать несколько случайных дочерних элементов на стороне клиента. Этот метод упоминался во многих сообщениях, например, в здесь . Очевидно, что у этого метода есть свои недостатки; например, при запросе через родительский узел большого размера (например, более 10 000 дочерних узлов) получение такой суммы каждый раз приведет к огромному использованию полосы пропускания, а также к нагрузке на стороне клиента (когда нам на самом деле требуется лишь небольшое количество детей)
2. Двигаемся дальше: другой подход, как описано здесь, который использует итератор, каким-то образом обходит весь нагрузка на стороне клиента, однако огромное использование полосы пропускания все еще может иметь место, поскольку мы каждый раз загружаем весь родительский узел.
3. Интересный подход описан в ответе Тома на странице это обсуждение в Firebase, в котором предлагается:
Хакерский способ сделать это - сгенерировать случайный ключ и выполнить запрос с помощью startAt().limit(1). У меня есть ощущение, что это может повредить производительности вашей базы огня, поэтому вы не должны выполнять эту операцию часто. У нас нет настоящей функции случайной выборки.
Это решение на самом деле звучит довольно хорошо, но я не уверен, как оно действительно повлияет на мою Firebase.
4. Другим глупым решением может быть ручное присвоение идентификаторам вопросов, так сказать, от 0 до N, поэтому обработка случайной группы идентификаторов на стороне клиента и выборка вопросов на месте, зная фактическое имя узлов.
<сильный>5. И, наконец, я придумал следующее решение, которое я спрашиваю, является ли оно более или менее жизнеспособным, чем те, что представлены выше: создание другого родителя, содержащего только идентификаторы вопросов, и при необходимости следует получить этот родитель, который намного легче, чем questions
родитель. Оттуда у меня были бы конкретные случайные идентификаторы, и мне нужно было бы стрелять только по этим детям. Чтобы лучше понять, что я имею в виду, посмотрите на картинку ниже:
Теперь из-за этого метода возникает следующая проблема: является ли назначение (скажем) 15 eventListeners
хорошей практикой? Может ли это на самом деле замедлить работу? (Примечание: это относится и к методам 3 и 4)
И, наконец, какой метод на самом деле является оптимальным при запросе из большой базы данных для некоторых случайных дочерних элементов?
databaseRef.child("questions").child("id_0001").addSingleValueEventListener(..)
за каждый случайный идентификатор, который я получил. - person Catalin Ghita   schedule 15.02.2018questions
. - person Catalin Ghita   schedule 15.02.2018