Background:
We have around 100 web sites of various sizes (in terms of indexable content)
and I'm trying to come up with the best architectural design from a performance
perspective.
- Each of the sites has a need for DEV, TEST and LIVE indices.
- The content on the sites divided into 5 groups (but its likely that there
will be more groups in future) which is similar enough to use the same schema,
solrconfig, synonyms, stopwords etc.
- From a search view they are distinct per website (i.e. only that sites
content should appear) .
- The indexing mechanism is the same for all sites (i.e. they all use the web
api)
- While not unlimited we have a fair bit of flexibility on servers (although
they are all virtual)
Questions:
- Is it better to
(a) have each site in it own core and webapp
e.g. /solr1/(DEV|TEST|LIVE) /solr2/(DEV|TEST|LIVE) etc
(b) have all the cores in one webapp
e.g. /solr1/(SITE1DEV|SITE1TEST|SITE1LIVE|SITE2DEV|SITE2TEST|SITE2LIVE)
etc
(c) have 3 cores per content group and have a filter query param in all queries
that only grabs that sites data
e.g./solr1/(CONTENTGRP1DEV|CONTENTGRP1TEST....).
(d) same as (c) except sharding across multiple servers
(e) have all the DEV's, TEST's and LIVE's on separate boxes with either the (b)
or (c) setup
eg. (b) box1: /solr1/(SITE1LIVE|SITE2LIVE...) c
/solr1/(ONTENTGRP1LIVE|ONTENTGRP2LIVE...)
Thanks For the help
Regards,
Dave
