Chris, 1) I'd put different types of data in different cores/instances, unless you reaaaally need to search them all together. By using only common attributes you are kind of killing the richness of data and your ability to do something useful with it.
2) I'd triple-check the "do a second database search and union the results when doing advanced searches on non indexed field" part if you are dealing with non-trivial query rate. 3) Some people have thousands of Solr cores. Not sure on how many machines, but it's all a function of data size, hardware specs, query complexity and rate. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Chris Masters <roti...@yahoo.com> > To: solr-user@lucene.apache.org > Sent: Tuesday, May 5, 2009 10:59:40 AM > Subject: Multi-index Design > > > Hi All, > > I'm [still!] evaluating Solr and setting up a PoC. The requirements are to > index > the following objects: > > - people - name, status, date added, address, profile, other people specific > fields like group... > - organisations - name, status, date added, address, profile, other > organisational specific fields like size... > - products - name, status, date added, profile, other product specific > fields > like product groups.. > > AND...I need to isolate indexes to a number of dynamic domains (customerA, > customerB...) that will grow over time. > > So, my initial thoughts are to do the following: > > - flatten the searchable objects as much as I can - use a type field to > distinguish - into a single index > - use multi-core approach to segregate domains of data > > So, a couple questions on this: > > 1) Is this approach/design sensible and do others use it? > > 2) By flattening the data we will only index common fields; is it > unreasonable > to do a second database search and union the results when doing advanced > searches on non indexed fields? Do others do this? > > 3) I've read that I can dynamically add a new core - this fits well with the > ability to dynamically add new domains; how scaliable is this approach? Would > it > be unreasonable to have 20-30 dynaimically created cores? I guess, redundancy > aside and given our one core per domain approach, we could easily spill onto > other physical servers without the need for replication? > > Thanks again for your help! > rotis
