lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: Solr Stream vs Export Request Handlers
Date Thu, 27 Sep 2018 08:32:31 GMT
Hi,

Yes, you can choose which to use, it should give  you about same result. If you already work
with the Solr search API it would be the easiest for you to consume /export as you don't need
to learn the new syntax and parse the Tuple response. However, if you need to do stuff with
the docs as you stream them from Solr, then streaming expressions lets you enrich the docs,
modify, join etc on the fly.

PS: When the /export docs says it uses a streaming tecnique, it does NOT mean that it has
uses the solr feature streaming expressions :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 27. sep. 2018 kl. 09:07 skrev Kamal Kishore Aggarwal <kkroyal.192@gmail.com>:
> 
> Hi,
> 
> I have a requirement to fetch all data from a collection. One way is to use
> streaming expression and other way is to use export.
> 
> Streaming expression documentation says *streaming functions are designed
> to work with entire result sets rather then the top N results like normal
> search. This is supported by the /export handler.*
> 
> Also, Export handler documentation says *this feature uses a stream sorting
> technique that begins to send records within milliseconds and continues to
> stream results until the entire result set has been sorted and exported.*
> 
> These two statements concludes to me that for fetching entire results
> streaming expressions uses export handler and export handler uses stream,
> so, whether I use streaming expression or export handler, they are
> internally same and would have same performance. I am correct over here to
> say so ?
> 
> 
> Ref Links:
> 
> https://lucene.apache.org/solr/guide/6_6/streaming-expressions.html
> https://lucene.apache.org/solr/guide/6_6/exporting-result-sets.html
> 
> 
> Regards
> Kamal Kishore


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message