Структура базы данных NoSQL для социальной сети типа Facebook - PullRequest
Новая
       5

Структура базы данных NoSQL для социальной сети типа Facebook

0 голосов
/ 22 сентября 2018

Для приложения социальной сети типа Facebook требуется высокопроизводительная структура базы данных для хранения данных в Firebase (NoSQL).

Данные для хранения: 

 - Userinfo (name, email etc)
 - Friends
 - Posts
 - Comments on posts.

Язапутан в следующих двух структурах БД относительно производительности запросов (если база данных становится огромной).

(Ref: C_xxx - это Collection, D_xxx - это документ)

Структура 1 

C_AllData
    - D_UserID-1
        name: xxxx,
        email: yyy,
        friends: [UserID-3, UserID-4]
        - C_Posts
            - D_PostId-1
                Text: hhh
                Date: zzz
                - C_Comments
                    - D_CommentId-1
                        UserID: 3
                        Text: kkk
                    - D_CommentId-2
                        UserID: 4
                        Text: kkk
            - D_PostId-2
                Text: hhh
                Date: zzz
                - C_Comments
                    - D_CommentId-3
                        UserID: 3
                        Text: kkk
                    - D_CommentId-4
                        UserID: 4
                        Text: kkk
    - D_UserID-2
        name: xxxx,
        email: yyy
        friends: [UserID-5, UserID-7]
        - C_Posts
            - D_PostId-3
                Text: hhh
                Date: zzz
                - C_Comments
                    - D_CommentId-5
                        UserID: 5
                        Text: kkk
                    - D_CommentId-6
                        UserID: 7
                        Text: kkk

Структура 2 

C_AllUsers 
    - D_UserID-1
        name: xxxx,
        email: yyy
        friends: [UserID-3, UserID-4]
    - D_UserID-2
        name: xxxx,
        email: yyy
        friends: [UserID-5, UserID-7]

C_AllPosts
    - D_PostId-1
        UserID: 1
        Text: hhh
        Date: zzz
        - C_Comments
            - D_CommentId-1
                UserID: 3
                Text: kkk
            - D_CommentId-2
                UserID: 4
                Text: kkk
    - D_PostId-3
        UserID: 2
        Text: hhh
        Date: zzz
        - C_Comments
            - D_CommentId-5
                UserID: 5
                Text: kkk
            - D_CommentId-6
                UserID: 7
                Text: kkk

Мой вопрос: каковы плюсы и минусы двух подходов?

Некоторые моменты, о которых я мог подумать, приведены ниже, пожалуйста, исправьте меня, если я ошибаюсь.

Структура 1:

Получает всепосты данного пользователя, быстрее в структуре 1?Поскольку мы точно указываем на точную коллекцию (AllData / {UserID} / Posts /)

Поскольку вся БД находится в одной коллекции, разве масштабируемость не хороша?

Структура 2:

Разделенная БД -> Лучшая масштабируемость?

Разделенная БД -> Лучшая производительность?

Меньшая вложенность -> Лучшая производительность?

AllPosts под однимколлекция -> Медленные запросы?

Или, если вы можете предложить лучшую модель, это тоже было бы здорово.

1 Ответ

0 голосов
/ 22 сентября 2018

В Firebase практическое правило - хранить отдельные типы сущностей в отдельных ветвях.Это особенно важно, потому что:

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

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

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

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

C_AllPosts
    - D_PostId-1
        UserID: 1
        Text: hhh
        Date: zzz
    - D_PostId-3
        UserID: 2
        Text: hhh
        Date: zzz
C_AllComments
    - D_PostId-1
        - D_CommentId-1
            UserID: 3
            Text: kkk
        - D_CommentId-2
            UserID: 4
            Text: kkk
    - D_PostId-3
        - D_CommentId-5
            UserID: 5
            Text: kkk
        - D_CommentId-6
            UserID: 7
            Text: kkk

Теперь, если вы хотите отобразить пост исвои комментарии, вам придется прочитать два узла.Если вы сделаете это для нескольких постов, у вас будет много операций чтения, чтобы по существу выполнить NoSQL-эквивалент SQL JOIN.Это вполне нормально, по сути это соединение на стороне клиента, и оно не такое медленное, как вы думаете, потому что Firebase передает запросы .

Для более подробного ознакомления с этим типом моделирования данных я рекомендую:

И эти ответы на предыдущие вопросы:

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...