Instead of putting things in a database, I would put an HTTP cache, like Varnish, in front of Solr. Then you get the best of both worlds. Fast fetches for things that have already been calculated and results for any query that shows up.
The client does not need special code to get the manually cached values. Everything is the same kind of HTTP request. An HTTP cache is extremely fast, almost certainly faster than a database. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Oct 17, 2018, at 8:29 AM, Shawn Heisey <apa...@elyograg.org> wrote: > > On 10/17/2018 9:19 AM, Joseph Costello - F&D Reports wrote: >> >> Any feedback from the group on the question below. >> >> The question was will solr performing distance calculations (10,000++) on >> the fly, perform faster than SQL query simply pulling pre-calculated >> distance values directly from the database. >> > > If your database contains pre-calculated values, then pulling those is likely > to be faster than doing calculations on the fly. Whether that's true in > practice depends on precisely what kinds of calculation you are doing, and > what must be done to obtain the values that go into the calculation. > > If your database has pre-calculated values, and you need those in search > results, why not just put the pre-calculated values into your Solr index when > you build it? One of the key things done with a search engine for > performance is handling as much as possible at index time, so there's less > work to do at query time. > > Thanks, > Shawn >
