I mean lots of geodist queries. I don't know sphinx's performance on geodist queries,
seems it computs geo-distance every time. Which is better compared to MySQL's spatial
Name: Barry Hunter
> Is sphinx capable of heavy geo-based services?
Certainly! I use it a lot. It's great. For simple X nearest is many times quicker that
mysql. A mysql spatial index performed amiciablly upto about 200,000 rows, but once got
more than that sphinx is way quicker.
The key is using a hybrid approach, if you do a sort and filter on geodist, then as you
mention it has to calculate the spherical distance for all results.
But by precomputing 'tiles' basically deviding up your 'world' into a grid, and the
saveing the 'tile' as a full text keyword. Then when searching you work out the likly
tiles, and search on them. The tile keywords provide broad filtering, cut down
drastically on the number of geodist calcs required. But still use geodist to do the
final refinement and sorting.
The trick is picking a good grid size. Too small, and need to add lots of terms to your
search query. Too big, and its not cutting down the number of results being searched much.
> I mean lots of geodist queries. I don't know sphinx's performance on geodist queries,
> seems it computs geo-distance every time. Which is better compared to MySQL's spatial
My Site (www.hourdb.com) takes in tons of requests a Sphinx backend. We pre-process
things such as zipcodes and city/state combo's into a lat&long pair, and then use Sphinx
to order the results. Albeit I'm using a modified version of the geodist calculation in
sphinx to improve accuracy, but it's super fast.
It's still really quick, and it takes tons of hits everyday. Less than 0.1 ms for worst
case scenario. The most important factor is to pre-limit to a fuzzy radius before
ordering by distance.