Hello Peter, well, I am no expert on Solr, but what you want to do sounds like a case for several SolrCores [1]. I am thinking of one core per portal and one super-core to search over all portals. This would be redundant and several information will be stored twice or more times. Another way would be to build one super-index. In your schema you have to define a field (let's call it "portal") to set to which portal it's "row" belongs. If you are searching for content from the news portal, you have to facet portal:news and so on.
Just some thoughts. Kind regards from Germany Mitch [1]http://wiki.apache.org/solr/CoreAdmin Peter Gabriel wrote: > > Hello! > > Our team wants to use solr for an community portal built up out of 3 and > more sub portals. We are unsure in which way we sould build up the whole > architecture, because we have more than one portal and we want to make > them all connected and searchable by solr. Could some experts help us on > these questions? > > - whats the best way to use solr to get the best performance for an huge > portal with >5000 users that might expense fastly? > - which client to use (Java,PHP...)? Now the portal is almost PHP/MySQL > based. But we want to make solr as best as it could be in all ways > (performace, accesibility, way of good programming, using the whole > features of lucene - like tagging, facetting and so on...) > > > We are thankful of every suggestions :) > > Thanks, > Peter > > -- View this message in context: http://old.nabble.com/Fundamental-questions-of-how-to-build-up-solr-for-huge-portals-tp27189739p27189905.html Sent from the Solr - User mailing list archive at Nabble.com.
