Thank you Shawn for your response. I would be running some performance tests lately on this structure (one JVM with multiple cores), and would share feedback on this thread.
>There IS a way to specify the solr home for a specific context, but keep >in mind that I definitely DO NOT recommend doing this. There is >resource and administrative overhead to running multiple copies of Solr >in one JVM. Simply run one context and let it handle multiple shards, >whether you choose SolrCloud or not. Due to distributed search feature, I might not be able to run SolrCloud. I would appreciate, if you please share that way of setting solr home for a specific context in Jetty-Solr. Its good to seek more information for comparison purposes. Do you think having multiple JVMs would increase or decrease performance. My document base is around 20 million rows (in 24 shards), with document size ranging from 100KB - 400 MB. SM On Mon, Feb 8, 2016 at 8:09 PM, Shawn Heisey <apa...@elyograg.org> wrote: > On 2/8/2016 1:14 AM, Shahzad Masud wrote: > > Thank you Shawn for your reply. Here is my structure of cores and shards > > > > Shard 1 = localhost:8983/solr_2014 [3 Core - Employee, Service Tickets, > > Departments] > > Shard 2 = localhost:8983/solr_2015 [3 Core - Employee, Service Tickets, > > Departments] > > Shard 3 = localhost:8983/solr_2016 [3 Core - Employee, Service Tickets, > > Departments] > > > > While searching, I use distributed search feature to search data from all > > three shards in respective cores e.g. If I want to search from Employee > > data for all three years, I search from Employee core of three contexts. > > This is legacy design, do you think this is okay, or this require > immediate > > restructure / design? I am going to try this, > > > > Context = localhost:8982/solr (9 cores - Employee-2014, Employee-2015, > > Employee-2016, ServiceTickets-2014, ServiceTickets-2015, > > ServiceTickets-2016, Department-2014, Department-2015, Department-2016] > > distributed search would be from all three cores of same data category > > (i.e. For Employee search, it would be from Employee-2014, Employee-2015, > > Employee-2016). > > With SolrCloud, you can have multiple collections for each of these > types and alias them together. Or you can simply have one collection > for employee, one for servicetickets, and one for department, with > SolrCloud automatically handling splitting those documents into the > number of shardsthat you specify when you create the collection. You > can also do manual sharding and split each collection on a time basis > like you have been doing, but then you lose some of the automation that > SolrCloud provides, so I do not recommend handling it that way. > > > Regarding one Solr context per jetty; I cannot run two solr contexts > > pointing to different data in Jetty, as while starting jetty I have to > > provide -Dsolr.solr.home variable - which ends up pointing to one data > > folder (2014 data) only. > > You do not need multiple contexts to have multiple indexes. > > My dev Solr server has exactly one Solr JVM, with exactly one context -- > /solr. That instance of Solr has 45 indexes (cores) on it. These 45 > cores are various shards for three larger indexes. I am not running > SolrCloud, but I certainly could. > > You can see 25 of the 45 cores in my Solr instance in this screenshot of > the admin UI for this server: > > https://www.dropbox.com/s/v87mxvkdejvd92h/solr-with-45-cores.png?dl=0 > > There IS a way to specify the solr home for a specific context, but keep > in mind that I definitely DO NOT recommend doing this. There is > resource and administrative overhead to running multiple copies of Solr > in one JVM. Simply run one context and let it handle multiple shards, > whether you choose SolrCloud or not. > > Thanks, > Shawn > >
