Constantijn, I am aware of this and we have already increased max boolean clauses to <3500> from the default <1200> for all our 200+ instances .
But the requirement is that we could have <n> number of products running to several thousands for each of the instances and since <n> is not defined , this will not scale considering <n> could be different for each of our instances and also the performance impact of so many Boolean clauses. Regards Sujatha On Fri, Jun 17, 2011 at 2:58 PM, Constantijn Visinescu <baeli...@gmail.com>wrote: > 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. > >>> > >> > > >
