Depends on your use cases. Having things in one index will generally
make things easier in the long run, and generally shouldn't be a
bottleneck. However, if the two types will be treated very differently
it may make sense to have two cores - say one type is not changed very
often, while the other will have tons of updates all day - might make
sense to split them up. Personally, I'd want a strong reason to limit
myself to multicore, and general performance won't differ enough to be
worth it generally. Solr is basically going to jump to the right records
the same way you would have to point it to the right core. You have both
though right? Do some benchmarks with your business logic.
- Mark
sanraj25 wrote:
Hi
Now I am using SOLR and two different type of data indexed and
searched.For ex:
1) JobRec
2) JobSel
I stored the data by specify type:JobRec similarly I specify
type:JobSel while indexing .If I want to retrieve the data i will get by
querying with type:job rec.
This is perfectly working.No problem
Now I create separate index for JobRec and JobSel using multicore concept.
My question is Which method faster and efficient.Somebody says multicore
method is better due to two different storage location.So whenever indexing
and retrieving load is very low when comparing same loaction.
please give some idea for better performance
Thanks
Sanraj R
