И вообще, NoSQL — это не магическая пуля. Вы точно также либо используете индексы (и получаете те же плюсы и минусы, что SQL), либо тупо используете из как key-value хранилище.
Но важно, конечно, сколько у вас пользователей, какая у них, активность, из этого можно прикинуть объемы и частоту запросов и делать выводы.
1) с дорогим SELECT, но дешевым INSERT: делаем табличку вида (user_id, event_id, time, event_details), при возникновении события делаем 1 INSERT, а чтобы прочитать ленту событий, выбираем id всех друзей пользователя и делаем SELECT * FROM events WHERE user_id IN :friendIds ORDER BY time DESC LIMIT :limit. Вставка дешевая, но выборка — не оптимизируется: мы либо используем ключ на time, либо на user_id, но не оба. То есть, при большой истории событий, большом числе событий или числе пользователей SELECT будет тормозить, дай бог каждому. Интуиция подсказывает мне что при сколько-либо серьезной нагрузке выборки с Filesort положат базу.
2) С дешевым селект, но дорогим инсертом. Это, когда мы ведем каждому юзеру в таблице свою ленту событий друзей, а при возникновении события вставляем его в ленты всем друзьям. SELECT здесь будет иметь вид SELECT * FROM events WHERE feed_user_id = :userId ORDER BY time DESCLIMIT :limit. При этом варианте, если у юзера есть 100 друзей и он к примеру загрузил фотку. надо сделать 100 INSERT в ленты всем его друзьям. Это вообще проигрышный вариант, хотя если хранение и «добавление в 100 лент нового события» переложить на плечи демона, шансы какие-то появляются.
Вы, как я понимаю, выступаете за вариант 1 с кешированием в noSQL части данных? А как вы кеш обновлять будете? Кто-то загрузил фотку, и вы сбрасываете ключи кеша у всех его друзей? Так в этом случае кеш будет постоянно сброшен и фактически бесполезен. А если делать обновление кеша у 100 друзей, так это 100 запросов к NoSQL хранилищу.
Я не вижу, чем тут поможет NoSQL — и 1) и 2) неэффективны при большом числе пользователей и друзей (хотя, я знаю, есть храбрые индусы, делающие ленты активности на PHP и MySQL, но не знаю, как они себя ведут под нагрузкой).
Потому вариант с демоном — это фактически вариант 1), только вместо использования БД, данные кешируются в памяти демона, если памяти есть гигабайты, а старые события удалять из кеша, то можно закешировать вообще все ленты всех пользователей проекта.
Потому что вряд ли сама по себе Джумла тормозит на таком железе. Может, например, ограничено число коннектов к БД, может какие блокировки, или еще что-нибудь.
То есть VARCHAR хранится физически там же где и остальные поля записи, а TEXT — отдельно, и с VARCHAR у вас запись занимает порядка 24 Кб, а с TEXT — запись занимает сотню байт.
> 30+30 тыс риэлтеру и за первый месяц аренды квартиры
Он же студент, пусть комнату снимает, и найдет агента не с 100, а с 50% агентских. Если есть друг, который хочет понаехать — еще лучше, можно снимать вдвоем 1 комнату за копейки. Все равно весь день будет на работе. Скромнее надо быть.
