Френдлента? Как такое задизайнить?

Под «френдлентой» ты имеешь в виду весь набор поисковых запросов одного пользователя?

Что вообще такое поисковой запрос? User has_many :searches , т.е. список запросов, которые он может создавать, удалять и модифицировать? Или как в твиттере - просто общий поиск?

Выполнять каждый раз все запросы по отдельности и склеивать их — дикость.

А склеивать и выполнять один большой запрос c LIMIT сколькотамутебя? Я не помню чтобы у Lucene было по этому поводу какое-то ограничение.

Дальше - в Lucene не так давно добавили какие-то изменения, позволяющие следить за запросами почти в риалтайме, в версии 2.9, чтоли, наверное будет полезно.

Для «общего» поиска кстати тот же твиттер ( и дигг, и некоторые другие ) все что можно предвычисляют, куча дубликатов получается, но диски дешевые. Насколько я понимаю если у тебя Couchdb, то нет join'ов, и дубликаты тоже так или иначе появятся, м?

>в Lucene не так давно добавили какие-то изменения,

http://wiki.apache.org/lucene-java/NearRealtimeSearch

> Что вообще такое поисковой запрос?

Вот пример документа и функции индексации для couchdb-lucene http://pastie.org/private/j2picqfcj7uw7zkygymwmw

Пример запроса «Jackson AND Color:(Black OR Red) AND Fingerboard:Ebony»

Пользователь должен уметь сохранить список таких запросов, следить за всеми изменениями и получать результаты. Обновил страницу — получил новые результаты выборки по своим запросам отсортированные по дате. Таких запросов может и сотня быть. Другими словами — сохранить поиск. Но смотреть его результаты не по отдельности, а вместе. Вопросов бы не было если бы по отдельности.

А склеивать и выполнять один большой запрос c LIMIT сколькотамутебя?

Это первое что мне пришло на ум, но как я уже сказал, нереально так как кол-во запросов может быть большое, + еще couchdb-lucene хочет запрос в виде querystring а строка эта, как известно, ограничена по длине. Да и не известно, как это все по скорости отработает.

Для «общего» поиска кстати тот же твиттер ( и дигг, и некоторые другие ) все что можно предвычисляют,

На диски пофигу, но тут это просто не возможно, я не представляю как это можно сделать. Я бы рад все ID совпадающих документов подсунуть к юзеру в документ, но ведь, это придется при внесении нового документа Item взять все возмжные сохраненные запросы и как-то проверить что документ удовлетворяет критерию — это просто не реально.

Насколько я понимаю если у тебя Couchdb, то нет join'ов, и дубликаты тоже так или иначе появятся, м?

Смотря что ты подразумеваешь под JOINами. Если JOIN как в SQL то в том виде конечно нет, но я могу допустим сохранить в одном документе ID связанного и потом в функции map его привязать и получу его вместе с исходным. Мне на JOINы пофигу, так как нормализации не будет, документы все однотипные и самодостаточные. Если же ты имеешь в виду объединение критериев запроса то я ля того и заюзал couchdb-lucene чтобы можно было сказать AND и OR. Стандартный диванный механизм выборки по ключу разве годится разве что... даже затрудняюсь как тут сострить можно.

Если интересно то вот как джойны делаются с недавних пор http://github.com/apache/couchdb/commit/926af4ba11093dcaff13bea0e4ed9addfc67ab10

> т.е. список запросов, которые он может создавать, удалять и модифицировать? Или как в твиттере - просто общий поиск?

Угу так точно. Ато я понаписал кучу всего.

>Я бы рад все ID совпадающих документов подсунуть к юзеру в документ, но ведь, это придется при внесении нового документа Item взять все возмжные сохраненные запросы и как-то проверить что документ удовлетворяет критерию — это просто не реально.

Насколько я понимаю - запросы более-менее постоянные. Строишь список всех критериев и ассоциируешь с каждым критерием запросы, к которым он относится. Не знаю, может в индексе люцена так уже и есть. Критерии самые примитивные - вместо запроса «Color:(Black OR Red)» будут два критерия Black и Red. Можно обозвать их токенами.

Я думаю поиск соответствия критериям в только что созданном документе(в таком же плоском, разложенном на токены документе) будет простым и быстрым, э? Просто пересекающиеся множества. Может быть если все еще недостаточно быстро это можно делать в каком-нибудь in-memory key-value store, redis как раз подходит, там есть атомарные операции над списками и хешами и он нехило быстрее memcached.

Дальше для каждого совпадения проходим ассоциируемые с критериями запросы с помощью например встроенного в couchdb mapreduce ( честно говоря не нашел док по нему на оф. вики ), записываем нужное в индекс или к юзеру, etc etc.

Больше на ум как-то ничего не приходит сейчас, голова слабо варит)

ох чую все уже давным давно придумано и решено. пойду читать книжки по алгоритмам.