Проектирование схемы Firebase для запроса Тенденции в сообщениях

Question

Я использую firebase в качестве Backend DataBase для сайта блога. Я хотел бы знать, как я могу структурировать свою Firebase DB; Основываясь на том, что я могу определить, какие должности чаще всего обсуждаются в последнее время.

Давайте рассмотрим следующий пример.

сообщений
  - [Сообщение 1]
                | -PostId: Post1
                | -PostName: OLD
                | -PostLikes: 100
                | -PostCreatedTimeStamp: 1483107180599
                | -PostCreatedDate: 20141204/* Формат даты в формате ГГГГММДД */
- [Сообщение 2]
                | -PostId: Post2
                | -PostName: NEW
                | -PostLikes: 40
                | -PostCreatedTimeStamp: 1483115276906
                | -PostCreatedDate: 20161204

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

Я также нашел временное решение. Создав аналогичный коэффициент.
LikeCoefficient = ((no of likes) * 10000000)/(Недавно опубликованныйTimeStamp- createdTimestamp).
Существует ошибка с этим подходом. Если трендовые сообщения перестают получать симпатии. Я не могу обновить коэффициент. Таким образом, старые сообщения могут появляться и между ними. (Я не хочу использовать сервер backend :). Это увеличит стоимость, которую я не хочу на этом этапе).
[Вопрос к Maths gigs:] Можем ли мы улучшить метод LikeCoefficient, чтобы представить порядок недавних трендов, созданных созданной меткой времени.

@FireBaseteam: Почему у нас нет двух параметров orderbychild. Почему команда почему .. :(:(

Answer 1

Вам нужна третья структура данных, чтобы поддерживать тренд должным образом. Алгоритмы трендов почти всегда являются «экспоненциальными скользящими средними» (EMA). Хотя это не единственная их цель, они обычно используются в биржевой торговле, и вы можете найти объяснение и формулу здесь:

http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:moving_averages

по существу то, что вы хотите сделать, это сохранить список насечки элементов вы можете иметь только один компонент, чтобы рассмотреть, что делает элемент ". тренд », например, комментарии публикуются, и в этом случае оценка для каждого элемента - всего 1.0. Но вы также можете делать умные вещи, например,« ответ на высший уровень стоит 1,0, а ответ второго уровня стоит 0,5 ". Вы можете включить все, что захотите, в эти алгоритмы - комментарии, ответы, рейтинги звезд или голоса, большие пальцы, акции и т. Д.

Выясните, как вы хотите весить или оценивать их, и создайте код, который добавит эти записи баллов к набору данных, когда они сделаны. В каждой записи вы, вероятно, захотите сохранить информацию о пользователе, который ее создал, о том, какое действие было выполнено, счет для этого действия, а также дату и время (в миллисекундах).

Оттуда вы просто применяете формулу EMA для создания общей взвешенной оценки для каждого сообщения. Одна очень приятная вещь в EMA заключается в том, что, хотя вы хотите запомнить список всех записей в баллах для последующей справки, нет необходимости запрашивать их все, чтобы настроить EMA для каждого нового значения. EMA можно рассчитать только по имеющимся данным, используя формулу в приведенной выше ссылке. А поскольку EMA предпочитают «новые» данные, они автоматически указывают трендовые элементы, потому что старые элементы выпадают.

Вам понадобится способ поддерживать эти значения с течением времени, как правило, фоновый/пакетный процесс, который помогает ускорить устаревание старых элементов. Альтернативно, пакетный процесс может вычислять CURRENT trending items и отправлять их в коллекцию /trending-posts, которая может быть отображена немедленно. Этот вариант - мое личное предпочтение, YMMV.