Антон Тихомиров

Здравствуй, собрат по несчастью :)
У меня аналогичная проблема, но я стал интегрироваться не с vk, а c pleer.com. К сожалению, они тоже быстро смекнули, что так трафика на всех не хватит и url-ы на песни имеют привязку к ip и access_token. Поэтому настроил проксирование с кешированием с помощью nginx (curl только для API).
Плюс в данном случае только один - не приходится качать музыку.
Но всё равно, трафик приходится пропускать через свой VPS. В принципе, я думаю, что не проблема доплатить за дополнительный трафик, если надо будет.

Как развернуть
Или можете использовать мой вариант. Если надо добавить функционал пишите

SELECT message FROM messages
WHERE user_id = ?
GROUP BY recepient_id
HAVING max(added)

abisab.com/wordpress/kak-udalit-url-adresa-iz-pois...

Только прочитайте внимательно, когда не следует этим пользоваться. Насколько я понимаю, в Вашем случае можно ничего не бояться.

Ну, join'ить это дело можно (подозреваю что там ещё и union'ом прийдётся заливать), но так обычно не делают, потому что это решение потом невозможно будет отмасштабировать. Запрос тяжелый, кеширование поможет плохо, так как активность большая и кеш часто сбрасываться будет и база будет дергаться не многим меньше, ну и если базу надо распилить на 2 и больше серверов, то останемся лапу сосать с join'ами.

Для начала можно сделать так - для конкретного `user_id` (владелец новостной ленты):
1) Первым запросом стягиваем айди всех друзей
2) Вторым запросом стягиваем айди всех групп, в которых состоит
3) Третьим запросом стягиваем из comments все записи WHERE `user_id` IN (группы + друзья) ORDER BY/LIMIT по вкусу.

Преимущества:
Меньшая нагрузка на базу, она будет делать меньше дорогостоящих операций с временными таблицами. По индексам быстрее будет отдавать результат.
Первые 2 запроса можно спокойно закешировать, так как добавляются/удаляются друзья гораздо реже, чем сами посты. Потому по сути сводится всё к одному запросу на сами посты без join'ов.

Минусы:
Больше кода на обработку 3х запросов. Чуть более длительное выполнения скрипта, что, в принципе, не будет ощущаться пользователем, и вообще будет не справедливо, если первые 2 запроса кешировать.

Но если стоит задача масштабироваться, то и такого подхода к делу недостаточно. Там уже надо будет скорее всего жертвовать лишним местом, чтобы сократить расходы на собирание размазанных данных по всем серверам баз, например, вести отдельную таблицу ленты новостей для каждого пользователя, которая будет агрегировать все необходимые айдишники.
UPD: ...как и указал @jarvis

Я делал через очередь сообщений, то есть сообщение человека или группы добавляется в ленты каждого его подписчика(многократно)

Все пока одна таблица(пока одна, потом придется увеличить в процессе масштабирования) и такой запрос на получение ленты пользователя с user_id: select * from 'feeds_table' where user_id=id пользователя...., а сама таблица feeds содержит такие поля как user_id( пользователь, которому принадлежит лента, author_id - id автора(кто оставил запись, без разницы группа или пользователь), post (сама запись и вложения). Таким образом запись многократно дублируется, но зато позволяет быстро и в один простой запрос получать ленту.