> ExternalFileField reads the data from the file once (per searcher) and
> then stores it in an internal data structure just like hte FieldCache - so
> it should be just as fast at query time as anything you might write using
> a SolrCache.
>
And if Solr instantiates a new searcher, the FieldCache would be
automatically regenerated?
> The one place where your specific biz logic might make a custom solution
> faster is if you know that typically only some small percentage of the
> values will be changing, and you have a fast way of getting those changes
> -- then you could have a CacheRegenerater that copies everything verbatim
> from the old cache to the new cache, and only overwrites the few values
> you know have changed. (ExternalFileField has to re-read the entire file
> each time)
>
The file is not big and as far as I understood, it is not necessary, since I
can access the old cache while the new one gets instantiated without any
delay. If not... I got a problem to solve in future. When Solr makes
real-time-search possible, this would become an important issue to solve,
because I need to get statistics with thousands of metrics. A solution would
be to create a SolrCache that only reconstructs itself after a hour or so.
That means that the metrics are not brand-new, but that's okay.
> Ah, i see what you ment -- you could use SolrJ for this if you wnat the
> logic to live outside Solr, but if you ultimately want the data inside
> solr (in a SolrCache) then i would suggest leaving SolrJ out of it and
> writing your logic directly as a Solr plugin.
>
Hm, how would you access data, normally offered by the statsComponent,
without the SolrJ?
I will have a look how the component computes its values, but I think this
is done by a complex way.
Another thing is, that I may need to create a subquery everytime my
functionQuery is called to retrive some newer statistics (of course the
response is much smaller than the externalFileField).
What I have in mind with SolrJ:
- when Solr 1.5 is released, the client does not need to know about the
different shards and cores
- I can be sure that the code that creates my response is up-to-date and
probably without of bugs
- I can send queries and get their full response
I don't want to reject your suggestion, but the alternative looks very
complex, perhaps too complex to start with. Or do I see the things too
complicated? It would be great, if there is any code-example of how to do it
the way you suggest it.
However, I understand that a software architect is confused, when the client
calls the server (function-query) and the server calls another client
(internal solrJ) to call the server again :-).
> the parsers produce new instances as needed, but the ValueSources that
> drive the FunctionQueries tend to be long lived (the most commonly used
> ValueSource is based on the FieldCache)
>
Okay, than I can store those statistics which I want to compute at
query-time in a map and reuse them for the whole function-query call (I mean
for every document).
Thank you, Chris.
- Mitch
--
View this message in context:
http://lucene.472066.n3.nabble.com/RequestHandler-function-Query-with-Cache-implementation-tp757610p766516.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
