Undef08Хотелось бы конечно онлайн.Заказчику действительно необходимо, что бы при добавлении 1000 постов в течение получаса вес тега пересчиталься именно 1000 раз, или достаточно пересчёта раз в час, если что-то менялось?

Хотя даже при онлайн пересчёте, если вес - всего-лишь количество упоминаний, то счётчик инкрементировать легко (или сделать некий пересчёт по инкрементированному счётчику).

DocAlА полнотекстовый поиск уже не справился?Конечно, полнотекстовый поиск будет медленнее для поиска по тегам.

Полнотекстовый поиск оптимальнее всего использовать только для полнотекстового поиска :-)

DocAl alexeyvgКонечно, полнотекстовый поиск будет медленнее для поиска по тегам.

Полнотекстовый поиск оптимальнее всего использовать только для полнотекстового поиска :-)А что, поиск по тегам идёт только по точному совпадению, без учёта релевантности и т.п.? По-моему, по описанию задачи, полнотекстовый поиск -- самая колбаса.Я, видя слово "тег", понял, что требуется точное совпадение.

Для неточного совпадения полнотекстовый поиск, конечно, проще в реализации, но всё равно медленнее.

Учёт релевантности, весов и т.п. проще, на мой взгляд, решаются без FTS.

Кот Матроскин alexeyvgХотя даже при онлайн пересчёте, если вес - всего-лишь количество упоминаний, то счётчик инкрементировать легко (или сделать некий пересчёт по инкрементированному счётчику).

Если использовать инкремент счетчиков - поиск будет действительно происходить легко, но начнутся проблемы с транзакциями, которые вынуждены будут конкурировать за счетчики (в особенности за счетчики частых тегов с низким весом).Это зависит от дланны транзакций.

При коротких транзакциях (ведь на один запрос будет одна транзакция с одним обновлением одной или нескольких записей весов счётчиков) это не будет проблемой.

Ещё можно и архитектурку пооптимизировать - например, если это WEB-сайт, в приложении делаем кэш с счётчиками и сбасываем их иногда (раз в минуту), прибавляя накопленные значения. Но это-уж для совсем большой нагрузки.