I'm willing to bet a lot that the standard approach is to use a Server Side Langauge to customize the queries for the user . . . on the same core/set of cores.
The only reasons that my limited experience suggests for a 'core per user' is privacy/performance. Unless you have a very small set of users, I would think managing cores for LOTS of users to be PIA. Create one (takes time), replicate to it (takes MORE time), use it, destroy it after session expires (requires garbage collection program running pretty often)(LOTS more time/CPU resource taken up. I am happy to be corrected on any of this. Dennis Gearon Signature Warning ---------------- It is always a good idea to learn from your own mistakes. It is usually a better idea to learn from others’ mistakes, so you do not have to make them yourself. from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' EARTH has a Right To Life, otherwise we all die. ----- Original Message ---- From: Markus Jelsma <markus.jel...@openindex.io> To: solr-user@lucene.apache.org Cc: Adam Estrada <estrada.adam.gro...@gmail.com> Sent: Tue, November 9, 2010 3:57:34 PM Subject: Re: Using Multiple Cores for Multiple Users Hi, > All, > > I have a web application that requires the user to register and then login > to gain access to the site. Pretty standard stuff...Now I would like to > know what the best approach would be to implement a "customized" search > experience for each user. Would this mean creating a separate core per > user? I think that this is not possible without restarting Solr after each > core is added to the multi-core xml file, right? No, you can dynamically manage cores and parts of their configuration. Sometimes you must reindex after a change, the same is true for reloading cores. Check the wiki on this one [1]. > > My use case is this...User A would like to index 5 RSS feeds and User B > would like to index 5 completely different RSS feeds and he is not > interested at all in what User A is interested in. This means that they > would have to be separate index cores, right? If you view documents within an rss feed as a separate documents, you can assign an user ID to those documents, creating a multi user index with rss documents per user, or group or whatever. Having a core per user isn't a good idea if you have many users. It takes up additional memory and disk space, doesn't share caches etc. There is also more maintenance and your need some support scripts to dynamically create new cores - Solr currently doesn't create a new core directory structure. But, reindexing a very large index takes up a lot more time and resources and relevancy might be an issue depending on the rss feeds' contents. > > What is the best approach for this kind of thing? I'd usually store the feeds in a single index and shard if it's too many for a single server with your specifications. Unless the demands are too specific. > > Thanks in advance, > Adam [1]: http://wiki.apache.org/solr/CoreAdmin Cheers
