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).