Каков наилучший способ поиска в социальной сети, отдавая приоритет отношениям пользователей?

У меня настроена социальная сеть, и через API я хочу искать записи. База данных социальной сети — mysql. Я хочу, чтобы поиск возвращал результаты в следующем формате: Результаты, которые соответствуют запросу И являются друзьями пользователя, выполняющего поиск, должны иметь приоритет над результатами, которые просто соответствуют запросу.

Так можно ли это сделать в одном запросе или мне придется делать два отдельных запроса и объединять результаты и удалять дубликаты?

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

Спасибо


person john ryan    schedule 22.11.2009    source источник


Ответы (2)


Ссылка на Lucene немного усложняет уравнение. Давайте сначала решим его (или хотя бы получим базовый уровень) без него.

Предполагая следующую модель данных (или что-то похожее.

tblUsers
  UserId  PK
  UserName
  Age
  ...

tblBuddies
  UserId     FK to tblUsers.UserId
  FriendId   tblUsers.Userid  = Id of one of the friends
  BuddyRating     float 0.0 to 1.0 (or whatever normalized scale) indicating 
                  the level of friendship/similarity/whatever

tblItems
  ItemId  PK
  ItemName
  Description
  Price
  ...

tblUsersToItems
   UserId   FK to tblUsers.UserId
   ItemId   FK to 
   ItemRating   float 0.0 to 1.0 (or whatever normalized scale) indicating 
                the "value" assigned to item by user.

Наивный запрос (но хорошая основа для оптимизированного) может быть таким:

SELECT [TOP 25]  I.ItemId, ItemName, Description, SUM(ItemRating * BuddyRating)
FROM tblItems I
LEFT JOIN tblUserToItems UI ON I.ItemId = UI.ItemId
LEFT JOIN tblBuddies B ON UI.UserId = B.FriendId
WHERE B.UserId = 'IdOfCurrentUser'
  AND SomeSearchCriteria -- Say ItemName = 'MP3 Player'
GROUP BY I.ItemId, ItemName, Description
ORDER BY SUM(ItemRating * BuddyRating) DESC

Идея состоит в том, что данному предмету придается большее значение, если его рекомендует/использует друг. Дополнительный вес тем более важен, если друг является близким другом [BuddyRating] и/или если друг более настоятельно рекомендует этот товар [ItemRating].

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

Это тип идей / информации, которые вы ищете, или я пропустил вопрос?

person mjv    schedule 22.11.2009
comment
MJV, я не задавал вопрос, но я ищу ответ на проблему, которую вы опубликовали, - не могли бы вы предоставить свое решение lucene? - person EugeneMi; 16.10.2014
comment
@EugeneMi Боюсь, у меня нет решения Lucene. Я предоставил этот простой подход SQL, чтобы утверждать, что это, как правило, то, за чем ОП. В то время я бы добавил несколько фрагментов или указателей. Lucene, но я уже давно не работал с Solr или Lucene, и я, конечно, не знаком с последними функциями этих систем (в частности, на ум приходят повышение, автоматическое ранжирование ...), поэтому я бы даже не начал . - person mjv; 16.10.2014

Один из способов — хранить весь график вашей социальной сети отдельно от Lucene. Запустите свой запрос по ключевому слову в Lucene, а также найдите всех друзей в графе вашей сети. Для всех возвращенных друзей улучшите результаты поиска всех этих друзей на какой-либо коэффициент и курорт. Эта повторная сортировка будет выполнена за пределами Lucene. Я делал такие вещи раньше, и это работает довольно хорошо.

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

Граф вашей социальной сети может храниться в Mysql, в памяти как разреженная матрица смежности, или вы можете взглянуть на Нео4дж.

person bajafresh4life    schedule 23.11.2009