Посоветуйте эффективную структуру для реализации репостов/шаринга. Чтобы в один запрос получать ленту от друзей, включая расшаренные сообщения. Edited: Посоветуйте пожалуйста красивое и не слишком дорогое решение через один SQL-запрос. Дубль на SO: http://ru.stackoverflow.com/questions/433201/%D0%A1%D1%82%D ... post-share Желаемая основа для базы (но можно портить): http://sqlfiddle.com/#!9/85386/1
Эффективная структура тут - юзание nosql и мемкеша. Было на каком то хайлоад-ивенте, не помню за какой год, обсуждение такой тривиальной задачи как френдлента от твитура и вконтактика. И эта тривиальная задача, на самом деле - адов ад, потому что нагрузка на БД, даже при малом количестве пользователей, огромнейшая. Мемкеш спасает, но, разумеется, если он уже "прогретый".
в redise или что юзаете и/или мемкеше держится канал юзера со всеми связанными записями сразу (или их тайтлами, не знаю зачем вам тела постов сразу понадобились, но вполне может и требоваться в тз сразу ленту с контентом отдать). При изменении постов отправляется задача воркеру который распихывает подружкам в каналы связанные с ними события (публикация поста и т.п. с его контентом который первично отдается клиенту). Данные дублируются в sql этим же воркером и периодически (в зависимости от требований ваших к отдаче) сваливаются на винты из хранилищ в памяти. С таблиц (или не из таблиц, в реляционном виде не обязательно, может быть и nosql на винтах, а sql выступать уже как резервное хранилище конечного уровня, которое в проекте дёргаем только чтобы восстановить после крашей данные) уже обратно тянутся когда/если ложится сервер и нужно вытянуть данные обратно в быстрые хранилища. На чистом sql такое не решается, если не для 100 пользователей проект. Соответственно реляционные структуры тут уже у вас могут быть какие хотите и какие оптимальнее. Раз на такой задаче задействуете уже решения не на sql, стало быть простые посты тоже можно отдавать из памяти и, второе следовательно, будете обучать существующие объекты и модели работать помимо таблиц с новыми типами хранилищ. Конкретный кейс: Изменился пост. 1. По ключу перезаписали его в хранилище в памяти если он там есть. 2. Слили на винты (sql or nosql) 3. Пошарили в каналы друзей в памяти. 4. Отдали пункт 3 на винты. Как то так, если понятно объяснил.
Друзья, давайте не залетать мыслью слишком далеко. Мне не надо хайлоад и носиквел. Обсудим чистый SQL! Будем умеренно оптимизировать, ок?
Тк ты жеж не показал что у тебя там хайлоад или не хайлоад. И как это всё будет выглядеть в боевых условиях. Может у тебя там сервис который будет регулярно дергать такие запросы в открытом окне клиента. Тогда и сотня юзеров положить базу смогут. А так то если смотреть без или и если, то твои структуры вполне годятся. Если отдавать раз в сколько-то минут можно и нет риалтайма, то вообще в кронтаб скрипт и кеши запросов им шить и всё будет нормально. Если попридираться, и опять же, ванговать требования к твоему приложению, и опять же если отдаешь всё с винтов в режиме риалтайма, то я бы отдельную таблицу для таких штук сшивал, чтобы не было всяких тяжелых многотабличных выборок на боевой базе.
Это правда, детали я не написал. Дополнил первый пост уточнением: интересует конкретно SQL. Будем считать, что цель это не еще один фейсбук, а что-то попроще. Структура и небольшой пример в ссылке на sqlfiddle, чтобы было с чего начать.