[
https://issues.apache.org/jira/browse/SOLR-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202936#comment-14202936
]
Steve Davids commented on SOLR-4587:
------------------------------------
I agree that the Luwak approach provides clever performance optimizations by
removing unnecessary queries upfront. Though, Luwak doesn't really solve
providing "percolator-like functionality", just provides an optimized matching
algorithm. There is a decent amount of work here to allow clients to register
queries in a Solr cluster and provide an API to pass a document and have it get
matched against registered queries in a distributed manor, none of which is
handled by Luwak. I personally believe this ticket can be implemented without
Luwak's optimizations and provide value. We could provide a usage caveat that
you might not want to register more than 20k queries per shard or so, or if
they want to register more queries they can shard out their profiling/matcher
collection to take advantage of additional hardware. We can provide an initial
implementation then optimize the matching once Luwak dependencies are
completed, but from an outside-in perspective the API would remain the same but
matching would just be faster at a future point.
Does it make sense to others to start with an initial approach then provide
optimizations in future releases just as long as the API remains the same?
> Implement Saved Searches a la ElasticSearch Percolator
> ------------------------------------------------------
>
> Key: SOLR-4587
> URL: https://issues.apache.org/jira/browse/SOLR-4587
> Project: Solr
> Issue Type: New Feature
> Components: SearchComponents - other, SolrCloud
> Reporter: Otis Gospodnetic
> Fix For: Trunk
>
>
> Use Lucene MemoryIndex for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
