Re: Personalized search parameters

[Diego Ceccarelli (BLOOMBERG/ LONDON)]

I'm assuming that you are writing the cosine similarity and you have two 
vectors containing the pairs . The two vectors could have 
different sizes because they only contain the terms that have tfidf != 0.
if you want to compute cosine similarity between the two lists you just have to 
consider the pairs that appears in **both the vectors**, because otherwise if a 
term doesn't appear in one of the two the product is going to be 0, so it will 
not contribute to the final tfidf score. 

(Really old) Example: 
https://github.com/diegoceccarelli/dexter/blob/fb4bbcb27a13da2665f3c19d6c75bfc4f5778440/dexter-core/src/main/java/it/cnr/isti/hpc/dexter/lucene/LuceneHelper.java#L386


From: solr-user@lucene.apache.org At: 01/06/18 17:24:07To:  
solr-user@lucene.apache.org
Subject: Re: Personalized search parameters

Don't we need vectors of the same size to calculate the cosine similarity? 
Maybe I missed something, but following that example it looks like i have to
manually recreate the sparse vectors, because the term vector of a document
should (i may be wrong) contain only the terms that appear in that document.
Am I wrong?

Given that i assumed (and that example goes in that direction) that we have
to manually create the sparse vector by first collecting all the terms and
then calculating the tf-idf frequency for each term in each document.
That's what i did, and I obtained vectors of the same dimension for each
document, i was just wondering if there was a better optimized way to obtain
those sparse vectors.


--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[marco]

Don't we need vectors of the same size to calculate the cosine similarity? 
Maybe I missed something, but following that example it looks like i have to
manually recreate the sparse vectors, because the term vector of a document
should (i may be wrong) contain only the terms that appear in that document.
Am I wrong?

Given that i assumed (and that example goes in that direction) that we have
to manually create the sparse vector by first collecting all the terms and
then calculating the tf-idf frequency for each term in each document.
That's what i did, and I obtained vectors of the same dimension for each
document, i was just wondering if there was a better optimized way to obtain
those sparse vectors.



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[Diego Ceccarelli]

Maybe I misunderstood the question, but why you need to create the
full size vectors? can't you just compute the cosine using the sparse
vectors?

On Fri, Jan 5, 2018 at 10:09 PM, marco  wrote:
> At the moment I have another problem: is there an efficient way to calculate
> the cosine similarity between  documents?
> I'm following (with the required modifications)  THIS
>    code that calculates the cosine
> similarity between 2 documents, but it doesn't look too efficient when it
> comes to repeat everything between the user profile and every document
> retreived by the query.
> This because the termvectors returned by the IndexSearcher function
> getTermVector(...) only contain the terms present in the associated
> document, forcing you to create manually the full vectors.
> Isn't there the possibility to obtain full size vectors? (or are they way
> too big?)
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[marco]

At the moment I have another problem: is there an efficient way to calculate
the cosine similarity between  documents?
I'm following (with the required modifications)  THIS
   code that calculates the cosine
similarity between 2 documents, but it doesn't look too efficient when it
comes to repeat everything between the user profile and every document
retreived by the query. 
This because the termvectors returned by the IndexSearcher function
getTermVector(...) only contain the terms present in the associated
document, forcing you to create manually the full vectors.
Isn't there the possibility to obtain full size vectors? (or are they way
too big?)



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[marco]

This looks like a very good solution actually.
In the mean time i started working in a different way: I created a custom
query componentan from there i accessed the list of results of the query,
and i was searching a way to reorder that list, but i'd be better look to
the RankQuery, it surely looks like a more standard and elegant solution.

Thank you, i'll let you know how it goes with both the methods.



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[Diego Ceccarelli (BLOOMBERG/ LONDON)]

From: solr-user@lucene.apache.org At: 01/05/18 15:35:46To:  
solr-user@lucene.apache.org
Subject: Re: Personalized search parameters

In particular we have to retrieve the documents with a normal search
followed by a result reranking phase where we calculate the cosine
similarity between the retrieved documents and the user profile.


> That's exactly what RankQuery can do for you. You can specify how many 
> results you want to retrieve using the 'normal search' and then define your 
> own RankQuery / QParserPlugin. See for example ReRankQParserPlugin. 

https://lucene.apache.org/solr/guide/7_2/query-re-ranking.html


You can return your type of RankQuery, that will have access to the 
TopDocsCollector, so there you can reorder the documents by cosine similarity.

https://lucene.apache.org/solr/6_6_0//solr-core/org/apache/solr/search/RankQuery.html


--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[marco]

First of all thank you for the reply.
I understand your idea, and that would make the thing a lot easyer, the
problem is that this system is being created as a university project, and we
were specifically asked to develop a personalized search system based on
result reranking.
In particular we have to retrieve the documents with a normal search
followed by a result reranking phase where we calculate the cosine
similarity between the retrieved documents and the user profile.

I'm still looking around on the web, and it seems like i have to deal with
search component, is it right?
An alternative would be to work with plain Lucene, having the ability to
directly instantiate and call QueryParser, Similarity and everithing else
would simplify everything, but it wouldn't be nearly as cool :)



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Personalized search parameters

[Erik Hatcher]

IMO you’re making this more complicated than it needs to be.

Forget for a moment where the user profile is stored.  Say user A likes 
turtles.  User B likes puppies.

User A queries, and this gets sent to Solr:  q=something&bq=turtles
User B queries: q=something&bq=puppies

I’d fetch the user preference details _before_ making the call to Solr, and 
augment the call to Solr with the user-specific boosting/parameters.

If you happen to store the user preferences in a Solr document, fetch that 
document in your application tier before making the call to Solr (and I’d 
suggest using a separate collection for user preferences).   Sure, that’s two 
Solr requests, but… no worries!   Fetching a single document from Solr that is 
likely cached anyway won’t be slow.   And if you account for implementation 
time in your effort, it’s a big win. :)

For the record - this is the kind of thing we do in Lucidworks Fusion - sidecar 
collections, looking stuff up (preferences, recommendations, rules, etc etc) 
and augmenting the final/real Solr request.   Sounds kinda simplistic, and it 
is.  But the synergy of these simple things working together is Powerful Magic. 
  I’d hate to see you go down a really complicated and custom route to achieve 
what you’re asking, but I do empathize with the sentiment to roll all this 
together into a single Solr request hiding all the magic.   But simpler and 
straightforward is better than complex and custom if the end result is the same 
:)

Erik


> On Jan 5, 2018, at 6:10 AM, marco  wrote:
> 
> Hi, first of all I want to say that i'm a beginner with the whole Lucene/Solr
> environment.
> I'm trying to create a simple personalized search engine, and to do so i was
> thinking about adding a parameter user= to the uri of the query
> requests, that i would need during the scoring phase to rerank the result on
> based on the user profile (stored as a normal document).
> 
> My question is: how can i create a custom Similarity class that is able to
> retrieve a parameter passed during the request phase? I "know" from this 
> https://medium.com/@wkaichan/custom-query-parser-in-apache-solr-4634504bc5da
> <https://medium.com/@wkaichan/custom-query-parser-in-apache-solr-4634504bc5da>
>   
> that extending QParsePlugin I can access the request parameters, but how can
> i pass them during the whole chain of search operations so that they are
> accessible during the scoring phase?
> 
> Thank you for your help.
> 
> 
> 
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Personalized search parameters

[marco]

Hi, first of all I want to say that i'm a beginner with the whole Lucene/Solr
environment.
I'm trying to create a simple personalized search engine, and to do so i was
thinking about adding a parameter user= to the uri of the query
requests, that i would need during the scoring phase to rerank the result on
based on the user profile (stored as a normal document).

My question is: how can i create a custom Similarity class that is able to
retrieve a parameter passed during the request phase? I "know" from this 
https://medium.com/@wkaichan/custom-query-parser-in-apache-solr-4634504bc5da
<https://medium.com/@wkaichan/custom-query-parser-in-apache-solr-4634504bc5da>  
that extending QParsePlugin I can access the request parameters, but how can
i pass them during the whole chain of search operations so that they are
accessible during the scoring phase?

Thank you for your help.



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Implement Efficient Personalized Search

[Yifu Diao]

Hi,
I am using Django-Haystack which connects Django with Solr.
I have a model called Item which is about webpages. I want to enable
personalized search so that users can search only the items they have
shared.
I solved the problem like this:

sqs = searchqueryset.auto_query(query).filter(primary_key__in=own_items_ids)
own_item_ids is a list of integers that I got from Django ORM.
primary_key is just the primary key of the Item model.

My questions is,
By observing the actual query in Solr, there are lots of OR(like
item_id=1 OR item_id=2 ...) So I guess the time complexity is O(n^2),
but I want to reduce it to O(n). I want to build a hash table of
own_item_ids, and query this hash table while scanning the results
linearly so that I can get the filtered results.
Is this possible, if yes, how?
I have passed this question to Haystack maillist, but the author said
he doesn't know about the underlying mechanism.

Thanks!
Yifu

Re: Personalized Search

[dc tech]

Excluding favorited items is an easier problem
- get the results
- get exclude list from db
- scan results and exclude the items in the item list

You'd have to do some code to manage 'holes' in the result list ie
fetch more etc.

You could marry this with the solr batch based approach to reduce the holes :
- Every night, update the item.users field. This can be simple string
type of  field.
- query with negative criteria ie
   content:search_term AND -users:userid
- then do the steps outlined earlier

On 5/21/10, Rih  wrote:
>>
>> - keep the SOLR index independent of bought/like
>
> - have a db table with user prefs on a per item basis
>
>
> I have the same idea this far.
>
> at query time, specify boosts for 'my items' items
>
>
> I believe this works if you want to sort results by faved/not faved. But how
> does it scale if users already favorited/liked hundreds of item? The query
> can be quite long.
>
> Looking forward to your idea.
>
>
>
> On Thu, May 20, 2010 at 6:37 PM, dc tech  wrote:
>
>> Another approach would be to do query time boosts of 'my' items under
>> the assumption that count is limited:
>> - keep the SOLR index independent of bought/like
>> - have a db table with user prefs on a per item basis
>> - at query time, specify boosts for 'my items' items
>>
>> We are planning to do this in the context of document management where
>> documents in 'my (used/favorited ) folders' provide a boost factor
>> to the results.
>>
>>
>>
>> On 5/20/10, findbestopensource  wrote:
>> > Hi Rih,
>> >
>> > You going to include either of the two field "bought" or "like" to per
>> > member/visitor OR a unique field per member / visitor?
>> >
>> > If it's one or two common fields are included then there will not be any
>> > impact in performance. If you want to include unique field then you need
>> to
>> > consider multi value field otherwise you certainly hit the wall.
>> >
>> > Regards
>> > Aditya
>> > www.findbestopensource.com
>> >
>> >
>> >
>> >
>> > On Thu, May 20, 2010 at 12:13 PM, Rih  wrote:
>> >
>> >> Has anybody done personalized search with Solr? I'm thinking of
>> including
>> >> fields such as "bought" or "like" per member/visitor via dynamic fields
>> to
>> >> a
>> >> product search schema. Another option is to have a multi-value field
>> that
>> >> can contain user IDs. What are the possible performance issues with
>> >> this
>> >> setup?
>> >>
>> >> Looking forward to your ideas.
>> >>
>> >> Rih
>> >>
>> >
>>
>> --
>> Sent from my mobile device
>>
>

-- 
Sent from my mobile device

Re: Personalized Search

[dc tech]

In our specific case, we would get the user's folders and then do a
function query that provides a boost if the document.folder is in {my
folder list}.

Another approach that will work for our intranet use is to add the
userids in a multi-valued field as others have suggested.



On 5/20/10, MitchK  wrote:
>
> Hi dc,
>
>
>
>> - at query time, specify boosts for 'my items' items
>>
> Do you mean something like document-boost or do you want to include
> something like
> "OR myItemId:100^100"
> ?
>
> Can you tell us how you would specify document-boostings at query-time? Or
> are you querying something like a boolean field (i.e. isFavorite:true^10) or
> a numeric field?
>
> Kind regards
> - Mitch
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Personalized-Search-tp831070p832062.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

-- 
Sent from my mobile device

Re: Personalized Search

[Geert-Jan Brits]

Just want to throw this in: If you're worried about scaling, etc. you could
take a look at item-based collaborative filtering instead of user based.
i.e:
DO NIGHTLY/ BATCH:
- calculate the similarity between items based on their properties

DO ON EACH REQUEST
- have a user store/update it's interest as a vector of item-properties. How
to update this based on click / browse behavior is the interesting thing and
depends a lot on your environment.
- Next is to recommend 'neighboring' items that are close to the defined
'interest-vector'.

The code is similar to user-based colab. filtering, but scaling is invariant
to the nr of users.

other advantages:
- new items/ products can be recommended as soon as they are added to the
catalog (no need for users to express interest in them before the item can
be suggested)

disadvantage:
- top-N results tend to be less dynamic then when using user-based colab.
filtering.

Of course, this doesn't touch on how to integrate this with Solr. Perhaps
some combination with Mahout is indeed the best solution. I haven't given
this much thought yet I must say.
For info on Mahout Taste (+ an explanation on item-based filtering vs.
user-based filtering) see:
http://lucene.apache.org/mahout/taste.html

Cheers,
Geert-Jan

2010/5/21 Rih 

> >
> > - keep the SOLR index independent of bought/like
>
> - have a db table with user prefs on a per item basis
>
>
> I have the same idea this far.
>
> at query time, specify boosts for 'my items' items
>
>
> I believe this works if you want to sort results by faved/not faved. But
> how
> does it scale if users already favorited/liked hundreds of item? The query
> can be quite long.
>
> Looking forward to your idea.
>
>
>
> On Thu, May 20, 2010 at 6:37 PM, dc tech  wrote:
>
> > Another approach would be to do query time boosts of 'my' items under
> > the assumption that count is limited:
> > - keep the SOLR index independent of bought/like
> > - have a db table with user prefs on a per item basis
> > - at query time, specify boosts for 'my items' items
> >
> > We are planning to do this in the context of document management where
> > documents in 'my (used/favorited ) folders' provide a boost factor
> > to the results.
> >
> >
> >
> > On 5/20/10, findbestopensource  wrote:
> > > Hi Rih,
> > >
> > > You going to include either of the two field "bought" or "like" to per
> > > member/visitor OR a unique field per member / visitor?
> > >
> > > If it's one or two common fields are included then there will not be
> any
> > > impact in performance. If you want to include unique field then you
> need
> > to
> > > consider multi value field otherwise you certainly hit the wall.
> > >
> > > Regards
> > > Aditya
> > > www.findbestopensource.com
> > >
> > >
> > >
> > >
> > > On Thu, May 20, 2010 at 12:13 PM, Rih  wrote:
> > >
> > >> Has anybody done personalized search with Solr? I'm thinking of
> > including
> > >> fields such as "bought" or "like" per member/visitor via dynamic
> fields
> > to
> > >> a
> > >> product search schema. Another option is to have a multi-value field
> > that
> > >> can contain user IDs. What are the possible performance issues with
> this
> > >> setup?
> > >>
> > >> Looking forward to your ideas.
> > >>
> > >> Rih
> > >>
> > >
> >
> > --
> > Sent from my mobile device
> >
>

Re: Personalized Search

[Rih]

>
> - keep the SOLR index independent of bought/like

- have a db table with user prefs on a per item basis


I have the same idea this far.

at query time, specify boosts for 'my items' items


I believe this works if you want to sort results by faved/not faved. But how
does it scale if users already favorited/liked hundreds of item? The query
can be quite long.

Looking forward to your idea.



On Thu, May 20, 2010 at 6:37 PM, dc tech  wrote:

> Another approach would be to do query time boosts of 'my' items under
> the assumption that count is limited:
> - keep the SOLR index independent of bought/like
> - have a db table with user prefs on a per item basis
> - at query time, specify boosts for 'my items' items
>
> We are planning to do this in the context of document management where
> documents in 'my (used/favorited ) folders' provide a boost factor
> to the results.
>
>
>
> On 5/20/10, findbestopensource  wrote:
> > Hi Rih,
> >
> > You going to include either of the two field "bought" or "like" to per
> > member/visitor OR a unique field per member / visitor?
> >
> > If it's one or two common fields are included then there will not be any
> > impact in performance. If you want to include unique field then you need
> to
> > consider multi value field otherwise you certainly hit the wall.
> >
> > Regards
> > Aditya
> > www.findbestopensource.com
> >
> >
> >
> >
> > On Thu, May 20, 2010 at 12:13 PM, Rih  wrote:
> >
> >> Has anybody done personalized search with Solr? I'm thinking of
> including
> >> fields such as "bought" or "like" per member/visitor via dynamic fields
> to
> >> a
> >> product search schema. Another option is to have a multi-value field
> that
> >> can contain user IDs. What are the possible performance issues with this
> >> setup?
> >>
> >> Looking forward to your ideas.
> >>
> >> Rih
> >>
> >
>
> --
> Sent from my mobile device
>

Re: Personalized Search

[Rih]

Well, it's not really a recommendation engine per se but more of a filter
for the user. Say, I already own some stuff from the result set, I just want
to exclude them from the results. What I'm concerned with is reindexing the
document everytime someone marks/votes/likes/boughts.


On Thu, May 20, 2010 at 11:04 PM, Ken Krugler
wrote:

>
> On May 19, 2010, at 11:43pm, Rih wrote:
>
>  Has anybody done personalized search with Solr? I'm thinking of including
>> fields such as "bought" or "like" per member/visitor via dynamic fields to
>> a
>> product search schema. Another option is to have a multi-value field that
>> can contain user IDs. What are the possible performance issues with this
>> setup?
>>
>
> Mitch is right, what you're looking for here is a recommendation engine, if
> I understand your question properly.
>
> And yes, Mahout should work though the Taste recommendation engine it
> supports is pretty new. But Sean Owen & Robin Anil have a "Mahout in Action"
> book that's in early release via Manning, and it has lots of good
> information about Mahout & recommender systems.
>
> Assuming you have a list of recommendations for a given user, based on
> their past behavior and the recommendation engine, then you could use this
> to adjust search results. I'm waiting for Hoss to jump in here on how best
> to handle that :)
>
> -- Ken
>
> 
> Ken Krugler
> +1 530-210-6378
> http://bixolabs.com
> e l a s t i c   w e b   m i n i n g
>
>
>
>
>

Re: Personalized Search

[Rih]

It will likely be what you suggested, one or two multi value fields. But
with 10,000+ members, does Solr scaled with this schema?


On Thu, May 20, 2010 at 6:27 PM, findbestopensource <
findbestopensou...@gmail.com> wrote:

> Hi Rih,
>
> You going to include either of the two field "bought" or "like" to per
> member/visitor OR a unique field per member / visitor?
>
> If it's one or two common fields are included then there will not be any
> impact in performance. If you want to include unique field then you need to
> consider multi value field otherwise you certainly hit the wall.
>
> Regards
> Aditya
> www.findbestopensource.com
>
>
>
>
> On Thu, May 20, 2010 at 12:13 PM, Rih  wrote:
>
> > Has anybody done personalized search with Solr? I'm thinking of including
> > fields such as "bought" or "like" per member/visitor via dynamic fields
> to
> > a
> > product search schema. Another option is to have a multi-value field that
> > can contain user IDs. What are the possible performance issues with this
> > setup?
> >
> > Looking forward to your ideas.
> >
> > Rih
> >
>

Re: Personalized Search

[Ken Krugler]

On May 19, 2010, at 11:43pm, Rih wrote:

Has anybody done personalized search with Solr? I'm thinking of  
including
fields such as "bought" or "like" per member/visitor via dynamic  
fields to a
product search schema. Another option is to have a multi-value field  
that
can contain user IDs. What are the possible performance issues with  
this

setup?


Mitch is right, what you're looking for here is a recommendation  
engine, if I understand your question properly.


And yes, Mahout should work though the Taste recommendation engine it  
supports is pretty new. But Sean Owen & Robin Anil have a "Mahout in  
Action" book that's in early release via Manning, and it has lots of  
good information about Mahout & recommender systems.


Assuming you have a list of recommendations for a given user, based on  
their past behavior and the recommendation engine, then you could use  
this to adjust search results. I'm waiting for Hoss to jump in here on  
how best to handle that :)


-- Ken


Ken Krugler
+1 530-210-6378
http://bixolabs.com
e l a s t i c   w e b   m i n i n g

Re: Personalized Search

[MitchK]

Hi dc,



> - at query time, specify boosts for 'my items' items 
> 
Do you mean something like document-boost or do you want to include
something like
"OR myItemId:100^100"
?

Can you tell us how you would specify document-boostings at query-time? Or
are you querying something like a boolean field (i.e. isFavorite:true^10) or
a numeric field?

Kind regards
- Mitch
-- 
View this message in context: 
http://lucene.472066.n3.nabble.com/Personalized-Search-tp831070p832062.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Personalized Search

[dc tech]

Another approach would be to do query time boosts of 'my' items under
the assumption that count is limited:
- keep the SOLR index independent of bought/like
- have a db table with user prefs on a per item basis
- at query time, specify boosts for 'my items' items

We are planning to do this in the context of document management where
documents in 'my (used/favorited ) folders' provide a boost factor
to the results.



On 5/20/10, findbestopensource  wrote:
> Hi Rih,
>
> You going to include either of the two field "bought" or "like" to per
> member/visitor OR a unique field per member / visitor?
>
> If it's one or two common fields are included then there will not be any
> impact in performance. If you want to include unique field then you need to
> consider multi value field otherwise you certainly hit the wall.
>
> Regards
> Aditya
> www.findbestopensource.com
>
>
>
>
> On Thu, May 20, 2010 at 12:13 PM, Rih  wrote:
>
>> Has anybody done personalized search with Solr? I'm thinking of including
>> fields such as "bought" or "like" per member/visitor via dynamic fields to
>> a
>> product search schema. Another option is to have a multi-value field that
>> can contain user IDs. What are the possible performance issues with this
>> setup?
>>
>> Looking forward to your ideas.
>>
>> Rih
>>
>

-- 
Sent from my mobile device

Re: Personalized Search

[findbestopensource]

Hi Rih,

You going to include either of the two field "bought" or "like" to per
member/visitor OR a unique field per member / visitor?

If it's one or two common fields are included then there will not be any
impact in performance. If you want to include unique field then you need to
consider multi value field otherwise you certainly hit the wall.

Regards
Aditya
www.findbestopensource.com




On Thu, May 20, 2010 at 12:13 PM, Rih  wrote:

> Has anybody done personalized search with Solr? I'm thinking of including
> fields such as "bought" or "like" per member/visitor via dynamic fields to
> a
> product search schema. Another option is to have a multi-value field that
> can contain user IDs. What are the possible performance issues with this
> setup?
>
> Looking forward to your ideas.
>
> Rih
>

Re: Personalized Search

[MitchK]

Hi RiH,

I think the idea is interesting, but the approach you think of is a little
bit difficult to implement.
Imagine you got 10.000 users, than a Solr document must actually have 10.000
fields which are responsible to managing the whole stuff. Furthermore your
data will change quite often. So the probability of reindexing documents
would be high, since you want to update your fields on the fly to create the
best user experience.
So what I want to say is: the idea is good, but Solr seems to be the wrong
tool to do so *alone*.

I can imagine that Solr + a database + Mahout would be a good mixture. The
last one, Mahout unfortunately is not well documented at the moment (please,
correct me, if I am wrong).

Hope this is some usefull input for you.

- Mitch
-- 
View this message in context: 
http://lucene.472066.n3.nabble.com/Personalized-Search-tp831070p831245.html
Sent from the Solr - User mailing list archive at Nabble.com.

Personalized Search

[Rih]

Has anybody done personalized search with Solr? I'm thinking of including
fields such as "bought" or "like" per member/visitor via dynamic fields to a
product search schema. Another option is to have a multi-value field that
can contain user IDs. What are the possible performance issues with this
setup?

Looking forward to your ideas.

Rih