Дизайн базы данных для неповторяющихся элементов в фиде пользователей - PullRequest
Новая
       20

Дизайн базы данных для неповторяющихся элементов в фиде пользователей

0 голосов
/ 23 апреля 2019

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

Если пользователь A видел сообщение X , то сообщение X никогда не должно появляться в канале пользователя A .

Любая запись должна появляться в ленте новостей только один раз.

Для этого я создал следующие модели данных для SQL и NoSQL Базы данных.

NoSQL

Сообщения: 

{
    '_id': '56sd78',
    'title': 'this is some post'
}

Пользователи: 

{
    '_id': '6ds7'
    'reads':[
        '56sd78',
        '5sdthj8'

    ] // contains post id 

}

Выше я храню все сообщения _id, которые пользователь видел в коллекции пользователей как поле массива reads.

SQL

Сообщения: 

| id | title          |
|----|----------------|
| 1  | This is post 1 |
| 2  | This is post 2 |
| 3  | This is post 3 |

Пользователи: 

|  id  | username |
|------|----------|
|   1  |  abc     |
|   2  |  pqr     |
|   3  |  xyz     |

Считывает: 

|  id  | user_id | post_id |
|------|---------|---------|
|   1  |  1      |      2  |
|   2  |  1      |      3  |
|   3  |  2      |      2  |

Выше я храню все сообщения id, которые пользователь видел в отдельной таблице против пользователей id.

Какие решения идеально подходят для этого случая?

Имеет ли количество сообщений какое-либо отношение к выбору базы данных?

Есть ли лучший подход к этой проблеме?

Ответы [ 2 ]

0 голосов
/ 25 апреля 2019

Как вы упомянули, вы можете поддерживать детали постов в новостной ленте в NOSQL и отображение user_id на post_id в RDBMS.

Но сохранение каждого post_id пользователя в одной таблице может привести к снижению производительности в будущем.

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

Будет полезно использовать несколько разделов для разделения данных / строк на основе окна даты.

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

При отображении сообщений вам нужно получать данные как из таблицы NOSQL, так и из таблицы SQL. Наконец, объедините данные, возвращенные из обеих таблиц, а затем отбросьте записи, присутствующие в таблице SQL. Как и когда пользователь прокручивает страницы вниз для более старых сообщений, вы можете начать извлекать данные из более старых таблиц.

Sharding : Вам также необходимо рассмотреть возможность разделения пользователей базы данных для масштабирования миллионов пользователей.

0 голосов
/ 24 апреля 2019

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

Если ваша шкала мала, скажем, около 100 шагов в секунду, вы можете перейти к решению на основе RDBMS.но если вы ожидаете, что он будет расти, используйте nosql с подходом «только добавление», предпочтительно с столбчатой ​​БД, так что вы также пишете на несколько узлов.Что-то вроде 

[{
        '_id': '6ds7',
        'reads': '56sd78'
    },
    {
        '_id': '6ds7',
        'reads': '56sd7a'
    }
}]

Не обновлять текущую коллекцию.Хранилища данных NoSql структурированы в журнале (только добавление) при хранении, и обновление не является хорошей идеей.

...