At that scale, whatever you find administratively most convenient. You'll have a few economies of scale I think with a single core, but frankly I don't know if they'd be enough to measure. You say the docs are "quite large" though, are you talking books? Magazine articles? is 20K large or are the 20M?
One small tip: If you put them in the same core, use fq=source:whatever rather than AND. The fq clause will be set in the filterCache upon first use and will be faster than ANDing after that. If you set autowarm to a reasonable on filterCache they'll always be "hot". "Reasonable" here is on the order of 10-20... Best, Erick On Mon, Dec 4, 2017 at 4:20 PM, Phil Scadden <p.scad...@gns.cri.nz> wrote: > I have two different document stores that I want index. Both are quite small > (<50,000 documents though documents can be quite large). They are quite > capable of using the same schema, but you would not want to search both > simultaneously. I can see two approaches to handling this case. > 1/ Create a "source" field and use that identify which store is being used. > The search interface add the appropriate " AND source=xxxx" to queries. > 2/ Create separate core for each. > > If you want to use the same solr server to handle queries to both stores, > which is the best approach in terms of minimizing JVM size while keeping > searches reasonably fast? > Notice: This email and any attachments are confidential and may not be used, > published or redistributed without the prior written consent of the Institute > of Geological and Nuclear Sciences Limited (GNS Science). If received in > error please destroy and immediately notify GNS Science. Do not copy or > disclose the contents.
