Just to chip in my 2 cents: You know you can increase the max number of boolean clauses in the configuration files? Depending on your situation it might not be a permanent fix, but it could provide some instant relief.
Constantijn On Fri, Jun 17, 2011 at 11:19 AM, Peter Sturge <peter.stu...@gmail.com> wrote: > You'll need to be a bit careful using joins, as the performance hit > can be significant if you have lots of cross-referencing to do, which > I believe you would given your scenario. > > Your table could be setup to use the username as the key (for fast > lookup), then map these to your own data class or collection or > similar to hold your other information: products, expiry etc. > By using your own data class, it's then easy to extend it later if you > want to add additional parameters. (for example: HashMap<String, > MyDataClass>) > > When a search comes in, the user is looked up to retrieve the data > class, then its contents (as defined by you) is examined and the query > is processed/filtered appropriately. > > You'll need a bootstrap mechanism for populating the list in the first > place. One thing worth looking at is lazy loading - i.e. the first > time a user does a search (you lookup the user in the table, and it > isn't there), you load the data class (maybe from your DB, a file, or > index), then ad it to the table. This is good if you have 10's of > thousands or millions of users, but only a handful are actually > searching, some perhaps very rarely. > > If you do have millions of users, and your data class has heavy > requirements (e.g. many thousands of products + info etc.), you might > want to 'time-out' in-memory table entries, if the table gets really > huge - it depends on the usage of your system. (you can run a > synchronized cleanup thread to do this if you deemed it necessary). > > > On Fri, Jun 17, 2011 at 6:06 AM, Sujatha Arun <suja.a...@gmail.com> wrote: >> Alexey, >> >> Do you mean that we have current Index as it is and have a separate core >> which has only the user-id ,product-id relation and at while querying ,do a >> join between the two cores based on the user-id. >> >> >> This would involve us to Index/delete the product as and when the user >> subscription for a product changes ,This would involve some amount of >> latency if the Indexing (we have a queue system for Indexing across the >> various instances) or deletion is delayed >> >> IF we want to go ahead with this solution ,We currently are using solr 1.3 >> , so is this functionality available as a patch for solr 1.3?Would it be >> possible to do with a separate Index instead of a core ,then I can create >> only one Index common for all our instances and then use this instance to >> do the join. >> >> Thanks >> Sujatha >> >> On Thu, Jun 16, 2011 at 9:27 PM, Alexey Serba <ase...@gmail.com> wrote: >> >>> > So a search for a product once the user logs in and searches for only the >>> > products that he has access to Will translate to something like this . >>> ,the >>> > product ids are obtained form the db for a particular user and can run >>> > into n number. >>> > >>> > <search term> &fq=product_id(100 10001 ......n number) >>> > >>> > but we are currently running into too many Boolean expansion error .We >>> are >>> > not able to tie the user also into roles as each user is mainly any one >>> who >>> > comes to site and purchases a product . >>> >>> I'm wondering if new trunk Solr join functionality can help here. >>> >>> * http://wiki.apache.org/solr/Join >>> >>> In theory you can index your products (product_id, ...) and >>> user_id-product many-to-many relation (user_product_id, user_id) into >>> signle/different cores and then do join, like >>> f=search terms&fq={!join from=product_id to=user_product_id}user_id:10101 >>> >>> But I haven't tried that, so I'm just speculating. >>> >> >
