Дизайн системной базы данных для системы персонализированных рекомендаций по статьям - PullRequest
Новая
       53

Дизайн системной базы данных для системы персонализированных рекомендаций по статьям

0 голосов
/ 25 мая 2020

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

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

Мне было интересно, есть ли лучший способ спроектировать систему для масштабирования, т. Е. Должна ли система обрабатывать миллионы статей и миллионы пользователей?

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

1 Ответ

1 голос
/ 25 мая 2020

Пользователь сам определяет фильтры, и нужно ли рассылать новые статьи, соответствующие фильтрам? Похоже, что «предупредить меня, если появятся новые статьи»? каждая новая статья проверяет, фильтруют ли некоторые пользователи совпадение, и добавляют его в канал оповещения пользователя. (Для новой статьи сложность составляет O (n), где n - количество пользователей)

Если оценку фильтра можно легко нормализовать (и разделить на части), тогда сохраните фильтры отдельно и ссылку от фильтров пользователям, использующим этот фильтр. Затем вам нужно только оценить, соответствуют ли новые статьи фильтрам. (Для новой статьи сложность O (n), где n - количество фильтров)

Общие:

  • выгрузка пиков с помощью asyn c обработка всего этого . Например, помещайте новые статьи в очередь и работайте над ними шаг за шагом. Также для «канала оповещения» для каждого пользователя вы можете использовать pub / sub каналы

Другие идеи:

  • Рассмотрите возможность создания элемента-элемента (или элемента-пользователя) на основе рекомендации с существующими библиотеками и инструментами

И в целом увеличивайте сложность вашей оценки, когда это необходимо (можно начать с упрощения и с алгоритмом, который не идеально масштабируется, если он работает для вашего случая)

...