You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2006/08/25 19:35:14 UTC
[Solr Wiki] Trivial Update of "FederatedSearch" by YonikSeeley
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The following page has been changed by YonikSeeley:
http://wiki.apache.org/solr/FederatedSearch
------------------------------------------------------------------------------
If the merger were solr-schema aware, we could use the "external" form of the sort keys in the XML and still merge correctly by translating to index form before comparing.
- ==== Merging other data ===
+ ==== Merging other data ====
The information that could be merged would be from a pre-determined set.
* highlighting - easily merged
* debugging - might need tweaking of the debugging format to more easily pick out specific documents
@@ -76, +76 @@
Disadvantages:
* scalability not as good... if different index parts are committing frequently at different times, the retry rate goes up as the number of sub indicies increases.
+ Related Idea: allow the optional specification of a specific index version during querying, and
+ delay closing old indicies for a short amount of time (5 seconds... configurable) to allow requests to finish.
+
+
=== High Availability ===
How can High Availability be obtained on the query side?
* sub-searchers could be identified by VIPs (top-level-searcher would go through a load-balancer to access sub-searchers).