В текущей архитектуре мы сохраняем прогноз, исходящий от механизма рекомендаций, в виде списка идентификаторов элементов для каждого пользователя, список в настоящее время хранится в Redis.
Для каждого пользователя сохраняются все идентификаторы элементов.
Теперь мы хотим отфильтровать рекомендации для каждого пользователя, используя различные типы фильтров, и эта простая структура данных больше не подходит.
Первой моей идеей было сохранить таблицу, содержащую записи, подобные этой:
user_id | item_id | score
user001 item001 0.5
user001 item002 0.8
user003 item001 0.5
...
И еще одну таблицу, содержащую свойства элемента:
item_id | filter_1 | filter_2
item001 'a' 1
item002 'b' 5
item003 'c' 8
...
Тогда я мог быполучить рекомендации для конкретного пользователя, отфильтрованные по filter_1 или filter_2, выполнив INNER JOIN между двумя таблицами на основе item_id.
. Этот подход может работать, но он подходит для реляционныхбаза данных Я думал о денормализации одной таблицы:
user_id | filter_1 | filter_2 | item_id | score
user001 'a' 1 item001 0.5
user001 'a' 1 item002 0.8
user003 'c' 8 item001 0.5
Таким образом, нет необходимости в JOIN, и это ускоряет время запроса, решение также более масштабируемо.
Мне все еще интересно, является ли какое-либо из них лучшим решением, так как для нашей пользовательской базы нам придется хранить 300,000 X 500,000 = 150 Billions строк!Мне это кажется очень большим, и я думаю, что я что-то упустил, или я перебираю решение, которое может быть намного проще.
Мне было интересно, как эти данные структурированы в механизмах производственной рекомендации с большим количеством пользователей и предметов.