Полнотекстовый поиск устроен достаточно примитивно.
У всех. Разница только в нюансах.
1. Делится текст на отдельные слова, отбрасываются короткие и служебные слова.
2. Прогоняются слова через стемминг (отсекаются окончания)
snowball.tartarus.org/algorithms/russian/stemmer.html
3. По словам строится индекс что-то типа такого
roaringbitmap.org
Все - MySQL, PostgreSQL, SphinxSeach, ManticoreSearch, ElasticSearch - работают по такому алгоритму, когда речь идет о полнотекстовом поиске.
Качество поиска упирается в основном в п. 1 и 2. Плюс ручная заточка (дополнительный словарь и пр.)
Скорость поиска упирается в п. 3.
Есть небольшие отличия. Например, ElasticSearch умеет работать с индексом, который хранится на кластере из нескольких серверов. Таким образом, он не ограничен в размере индекса так жестко как SphixSearch (где принципиально, чтобы данные располагались на одном сервере).
С другой стороны - SphinxSearch и его форк ManticoreSearch -
чрезвычайно заточены на скорость. В частности, в них принята парадигма - игнорировать ошибки при построении индекса настолько настолько это возможно. Все ради скорости.
MySQL и PostgreSQL - не имеют никаких преимуществ ни по скорости (как Sphinx/Manticore) ни по объему индекса (как ElasticSearch). Их преимущества - простота использования, если у вас данные изначально хранятся в реляционной СУБД.
Нет, выхлопа по скорости при переходе на MySQL c Sphinx вы не получите.
Sphinx быстрее. От заточен именно на скорость.
Другое дело, что, возможно, вам не понадобится столь высокая заточенность на скорость у Sphinx. Возможно, удобство хранения в реляционной СУБД MySQL перевесит.
И да, непонятно зачем вам MongoDB. SphinxSearch уже давно может хранить и сами данные, а не только сам поисковый индекс.
Дополнительное обращение к MongoDB после того как документ уже найден в SphinxSearch - снижает производительность. Возможно, MongoDB удобна для каких-то видов работ, например, для инициации построения полнотекстового индекса. Но собственно в процессе полнотекстового поиска - она лишнее звено.
