Структура БД для обработки групп чатов, аналогичных Telegram / FB Messenger

Question

Структура БД для обработки групп чатов, аналогичных Telegram / FB Messenger

1

В настоящее время приложение чата, где пользователь может присоединиться к нескольким чат-группам, что-то похожее на то, что Telegram и Facebook Messenger есть. Довольно прямо. В основном мы используем базу данных Firebase для хранения групп чатов и деталей сообщений.

Пример структуры БД:

Чтобы получить только чат-группы, у пользователя есть:

root/
users/
  chatGroups/
    $uid/
      $chatGroupId: true

Затем мы получаем информацию о группе чатов с другого узла, то же самое с последним сообщением чата в этой группе:

root/
chatGroups/
  entries/
    $groupId/
      group details here...
  messages/
    $groupId/
      $messageId/
        message details here..

Все выше, чтобы получить данные для одного элемента группы, который выглядит примерно так:

Все работает нормально. Сначала мы сначала получаем не более 5 чат-групп, а затем просто сортируем список. Проблема заключается в том, что мы должны прислушиваться к обновлениям для групп чатов - группа с самым последним сообщением чата переместилась бы вверх.

Структура, которую мы слушаем только в списке групп, которые имеет конкретный пользователь, - мы могли бы обнаружить группы, объединенные (onChildAdded) и left (onChildRemoved) пользователем, но она не содержит отметки времени, которые нам нужны для сортировки списка групп чатов по последним изменениям.

Кто-нибудь пробовал подобное поведение с Firebase раньше (мы делаем клиент для Android и Web - Javascript)? Любые идеи или предложения будут оценены. Дайте мне знать, если вам нужны какие-то релевантные детали, чтобы сделать вещи более ясными.

AL. 20 окт. 2017, в 13:14

Источник

1

В таком случае я бы хотел сохранить lastUpdated времени lastUpdated в lastUpdated каждого пользователя, если это чат-группы, поэтому $chatGroupId: 1508508569108 . В зависимости от количества участников в группе обновление этих временных меток может быть довольно дорогой операцией разветвления. Но я не сразу вижу много других вариантов.
Frank van Puffelen 20 окт. 2017, в 14:10
0

@FrankvanPuffelen Спасибо, Пуф. Да уж. Мы думали об одном и том же. Мы ожидаем не более 300 пользователей в группе чата, так что да, было бы дорого писать каждому из них.
AL. 23 окт. 2017, в 04:48
0

Это действительно звучит слишком много. Сколько групп будет в среднем пользователь? Поскольку, если это меньше, вы также можете сохранить индекс идентификаторов групп для каждого пользователя, загрузить метаданные / lastmodified для каждой группы и упорядочить их на стороне клиента.
Frank van Puffelen 23 окт. 2017, в 14:12
0

Я предполагаю, что оценки будут составлять 10-20 групп на пользователя, у нас также есть пользователь, похожий на администратора, который может превышать от 50 до, возможно, 100. В настоящее время мы просто подключили пользователя и извлекли все данные. Для клиентской стороны я включил постоянную работу с дисками, надеюсь, это поможет уменьшить количество вызовов (без повторных вызовов). Но если мы когда-либо обнаружим, что это действительно дает пользователю плохой UX (более длительное время ожидания и т. Д.), Мы планируем пойти дальше и вместо этого внедрить ручное обновление (раскрывающееся обновление), которое мы считаем самым дешевым обходным решением. до сих пор.
AL. 24 окт. 2017, в 09:38
1

В этом случае я бы посоветовал держать слушателей в этих 10-20 группах, что означает, что вы получаете трафик только в случае изменения временной метки для группы - скорее всего, стабильный поток во времени.
Frank van Puffelen 24 окт. 2017, в 13:13

Показать ещё 3 комментария

Теги:

javascript

android

firebase

firebase-realtime-database

1 ответ

Ещё вопросы

В таком случае я бы хотел сохранить lastUpdated времени lastUpdated в lastUpdated каждого пользователя, если это чат-группы, поэтому $chatGroupId: 1508508569108 . В зависимости от количества участников в группе обновление этих временных меток может быть довольно дорогой операцией разветвления. Но я не сразу вижу много других вариантов.
@FrankvanPuffelen Спасибо, Пуф. Да уж. Мы думали об одном и том же. Мы ожидаем не более 300 пользователей в группе чата, так что да, было бы дорого писать каждому из них.
Это действительно звучит слишком много. Сколько групп будет в среднем пользователь? Поскольку, если это меньше, вы также можете сохранить индекс идентификаторов групп для каждого пользователя, загрузить метаданные / lastmodified для каждой группы и упорядочить их на стороне клиента.
Я предполагаю, что оценки будут составлять 10-20 групп на пользователя, у нас также есть пользователь, похожий на администратора, который может превышать от 50 до, возможно, 100. В настоящее время мы просто подключили пользователя и извлекли все данные. Для клиентской стороны я включил постоянную работу с дисками, надеюсь, это поможет уменьшить количество вызовов (без повторных вызовов). Но если мы когда-либо обнаружим, что это действительно дает пользователю плохой UX (более длительное время ожидания и т. Д.), Мы планируем пойти дальше и вместо этого внедрить ручное обновление (раскрывающееся обновление), которое мы считаем самым дешевым обходным решением. до сих пор.
В этом случае я бы посоветовал держать слушателей в этих 10-20 группах, что означает, что вы получаете трафик только в случае изменения временной метки для группы - скорее всего, стабильный поток во времени.

Alex Mamo · Answer 1 · 2017-10-20T08-50-00.000Z

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

Существует другой подход, в котором вы можете использовать денормализацию. Добавьте эти чаты в новый созданный раздел с именем uxChats. Чаты должны содержать только text message и timestamp. Если вы используете FirebaseUI, вы можете отменить порядок, просто используя эти строки кода:

LinearLayoutManager layoutManager = new LinearLayoutManager(getActivity());
layoutManager.setReverseLayout(true);
layoutManager.setStackFromEnd(true);
recyclerView.setLayoutManager(layoutManager)

Последний чат идет сверху.

Надеюсь, это поможет AL.

Привет, Алекс. Благодарю. Мы уже знаем о поведении и обычных механизмах. Я стремился к тому, чтобы кто-то предложил структуру, которая наилучшим образом использовала бы поведение Firebase DB, чтобы мы могли создать UX - новейший автоматический чат выходит на первое место .