First of all thank you for the repsonses/ideas. The plain idea is to boost products that are sold more for a specific customer. I'll discuss this with my customer to see if we can start with limited functionality as suggested by Walter.
Cheers, Jan. On 5 February 2016 at 17:33, Walter Underwood <wun...@wunderwood.org> wrote: > I would add a multiValued field for buying_customers. Add the customer ID > for each relevant customer to that field. Then use a boost query “bq”, to > boost those. > > Try that first before using the hit rate. Always try on/off control before > going proportional. The simple approach will probably give you 80% of the > benefit. Then you can declare victory and go on to the next idea. > > If you do need hit rate, try quantizing that into high/medium/low, or > deciles, or something. Then you have one multiValued field for each level > and one bq for each level. The bq will include a weight: > bq=customer_hi:1234^8. Logarithmic levels are probably your friend here. > > You can get some unwanted idf scoring with bq. Customers that only buy a > few things get a higher bq weight that customers that buy a lot of things. > You can fix that with function queries, but I’d get it working with a boost > query first. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > > On Feb 5, 2016, at 8:13 AM, Jack Krupansky <jack.krupan...@gmail.com> > wrote: > > > > This doesn't sound like a great use case for Solr - or any other search > > engine for that matter. I'm not sure what you are really trying to > > accomplish, but you are trying to put way too many balls in the air to > > juggle efficiently. You really need to re-conceptualize your problem so > > that it has far fewer moving parts. Sure, Solr can handle many millions > or > > even billions of documents, but the focus for scaling Solr is on more > > documents and more nodes, not incredibly complex or large documents. The > > key to effective and efficient use of Solr is that queries are "quite > > short", definitely not "quite long." > > > > That said, the starting point for any data modeling effort is to look at > > the full range of desired queries and that should drive the data model. > So, > > give us more info on queries, in terms of plain English descriptions of > > what the user is trying to achieve. > > > > > > -- Jack Krupansky > > > > On Fri, Feb 5, 2016 at 8:20 AM, Jan Verweij - Experts in search < > > j...@searchxperts.nl> wrote: > > > >> Hi, > >> We store 50K products stored in Solr. We have 10K customers and each > >> customer buys up to 10K of these products. Now we want to influence the > >> results by adding a field for every customer. > >> So we end up with 10K fields to influence the results on the buying > >> behavior of > >> each customer (personal results). Don't think this is the way to go so > I'm > >> looking for suggestions how to solve > >> this. > >> One other option would be to: 1. create one multivaluefield > >> 'company_hitrate' > >> 2. store for each company their [companyID]_[hitrate] > >> > >> During search use boostfields [companyID]_50 …. [companyID]_100 So in > this > >> case the query can become quit long (51 options) but the number of > >> fields is limited to 1. What kind of effect would this have on the > search > >> performance > >> Any other suggestions? > >> Jan. > >
