Full text search is arranged quite primitive.
At all. The difference is only in nuances.
1. Divides the text into individual words, and discarded short words.
2. Run the words through stemming (clipped end) snowball.tartarus.org/algorithms/russian/stemmer.html
3. According to the construction index something like this roaringbitmap.org
All - MySQL, PostgreSQL, SphinxSeach, ManticoreSearch, ElasticSearch work on the algorithm, when we are talking about full-text search.
Search quality rests mainly in 1 and 2. Plus manual sharpening (optional dictionary, etc.)
The search speed depends on p. 3.
There are small differences. For example, ElasticSearch is able to work with an index that is stored on a cluster of several servers. Thus, it is not limited in the size of the index is as tough as SphixSearch (where it is crucial that the data resides on a single server).
On the other hand, Sphinx and fork ManticoreSearch - extremely sharpened speed
. In particular, they accepted paradigm - ignore errors while building the index so much as it is possible. All for the sake of speed.
MySQL and PostgreSQL do not have any advantage nor speed (as a Sphinx/Manticore) or volume index (like ElasticSearch). Their advantages are ease of use if you have data originally stored in a relational DBMS.
No, the exhaust speed in the transition to MySQL with Sphinx you get. Sphinx faster. From imprisoned on speed.
Another thing is that, you may not need such a high sharpness on the speed of Sphinx. Perhaps the convenience of storage in a relational MySQL DBMS outweigh.
And Yes, it is not clear why do you need MongoDB. Sphinx has long been can store and the data itself, not only the search index. An additional call to the MongoDB after the document has been found in the Sphinx - reduces performance.
Maybe MongoDB is convenient for some types of work, for example, to initiate construction of the full-text index. But actually in the process of full-text search - it is an extra link.