Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><a href="http://shal.in" rel="nofollow noreferrer">Shalin Shekhar Mangar</a> answered me on the <a href="http://www.mail-archive.com/solr-user@lucene.apache.org/msg35011.html" rel="nofollow noreferrer">Solr-user mailing list</a> and by private email. Shalin is a contributor to Solr and an author of the upcoming book <em><a href="http://shal.in/post/335570903/solr-in-action-case-studies" rel="nofollow noreferrer">Solr in Action</a></em>. </p> <p><strong>His reply on the mailing list:</strong></p> <p>How would you setup the index(es)?</p> <blockquote> <p>I'd look at setting up multiple cores for each client. You may need to setup slaves as well depending on search traffic.</p> </blockquote> <p>Where do you store the index(es)?</p> <blockquote> <p>Setting up 5K cores on one box will not work. So you will need to partition the clients into multiple boxes each having a subset of cores.</p> </blockquote> <p>Would you need to add a filter to all search queries?</p> <blockquote> <p>Nope, but you will need to send the query to the correct host (perhaps a mapping DB will help)</p> </blockquote> <p>If a client cancelled, how would you delete their (part of the) index? (this may be trivial--not sure yet)</p> <blockquote> <p>With different cores for each client, this'd be pretty easy.</p> </blockquote> <p><strong>His reply by email:</strong></p> <blockquote> <p>I've worked on a similar use-case in the past and we used the multi-core approach with some heavy optimizations on the Solr side. See <a href="http://wiki.apache.org/solr/LotsOfCores" rel="nofollow noreferrer">http://wiki.apache.org/solr/LotsOfCores</a> - I haven't been able to push these changes into Solr yet.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload