Есть список друзей которые на-Like-али себе книг.
Теперь нужно получить список этих книг с сортировкой: сверху те книги где больше лайков от друзей.
Т.е. книга 1) всего лайков 1000, из них лайков друзей: 15 - будет ниже чем 2) всего лайков 200, из них лайков друзей: 25

Как это лучше хранить (и в чем) и как получить результат?

Максимум Лайков на один объект будет < 1000 (1 версия), < 1М (2 версия).

Сейчас в голове только один нормальный вариант выборки - загонять идентификаторы пользователей кто налайкал в sphinx (в разрезе объектов), и делать выборку по релевантности.

Получить список друзей, получить список книг к которым есть лайки и посчитать на python очень не эффективно ?

Ну это как-то топорно, у меня сейчас так и работает. По скорости пока терпит, думаю на будущее.
Думаю вдруг есть какой-то способ, не грузить из базы десятки тысяч объектов для получения первых 20-и.
(Понятно что что можно закешировать/за раннее готовить данные)

По идее это динамическое поле, т.е. получается, все равно все перебирать.
Ещё это можно сделать на mongodb aggregation framework (с версии 2.5.3), но на sphinx будет быстрее.

Нашел как чуть ускорить текущее решение, пока оставлю этот способ, когда прижмет - перепилю.

o7412369815963
ну это был не ответ выше.

Можно завести таблицу со значениями лайков для каждого пользователя. Например И когда происходит лайк выбирать друзей пользователя который лайкнул и в этой таблице к каждему пользователю к этой книге прибалять один (ну или создавать если нет). Если даже это действие очень дорогое можно положить это в очередь celery.

Таблица не верно - надо брать mongo или sorted sets redis, хотя наверно и в РСУБД такое можно хранить.

Вроде sorted sets вес может быть не больше 100(или нет), так-что хеши лучше. Даже команда есть для таких целей http://redis.io/commands/HINCRBY

Про такой вариант тоже думал, это получается своеобразное кеширование. Больше нагрузки будет когда пользователи будут фоловить других.
Если на пальцах посчитать: 100к пользователей, каждый фоловит по 200, каждый сделал по 500 лайков (-20% пересечений) х 2 байта = 15Гб индекс.
Думаю выгоднее будет вычислять без кеширования (т.е. купить cpu вместо памяти), (100к * 500 х 4байта (ссылка на пользователя) = 190Мб индекс)

Интересен был бы вариант с частичным кешированием, но есть ли такой?

Какая СУБД и какая структура таблиц?

o7412369815963
каждый фоловит по 200

Обычно для расчетов берут число Данбара (и кратные ему - только для краевых условий).
Вы осознанно взяли 200?

Lexander
Какая СУБД и какая структура таблиц?

Сейчас mongodb, в 2-х версиях, 1) отдельно коллекция событий, где есть: user_id, obj_id, when, и 2) в самом объекте массив ссылок на пользователей кто лайкнул.
1) Позволяет строить разные ленты “последних событий, последние лайкнутые”
2) Позволяет узнать лайкнул ли пользователь текущий объект без доп. запросов в БД

Lexander
Вы осознанно взяли 200?

Просто представил сколько могло бы быть в среднем.
Думаю число Данбара больше подходит для “друзей”, для фоловеров оно может быть больше.

Я бы сказал что это число бесполезное в интернете

Singularity
Я бы сказал что это число бесполезное в интернете

Бойтесь стереотипов, они серьезно мешают работе. :)
http://arxiv.org/abs/1105.5170

o7412369815963
Уточню на всякий случай, что сейчас число Данбара - это не константа, а диапазон - отражение разных сфер жизни, в том числе соцсетей.
Ваши 200 в него попадают, просто хотел понять насколько указанные 200 оправданны.

По теме пока ничего в понравившегося в голову не приходит.
Будет - отпишусь.

А можно постановку уточнить? Учитываются только лайки прямых друзей? Или друзья моих друзей мои друзья?