3

Currently i am using the REST interface to query vespa, which seems to work great but something tells me that i should be using searchers in the application to make the client(server side code) a bit lighter (bundle the jar file in the application package) to make it a bit smoother. I have managed to do some simple searcher/processor applications. But this is a bit overwhelming.

So are there any readily available examples ?

Basicially i want to:

  1. Send to /search?query=someId
  2. Do a ordinary search for the weighted set on this documentID (I guess this one can be handy: https://docs.vespa.ai/documentation/reference/inspecting-structured-data.html)
  3. Take those items in the response and add it to a wand item(s) and query for a wand with wandsearcher on a given field. Similar to the yql: "select * from sources * where wand(interest, some weightedsets));","ranking":"combined_score" and return the matches.

Just curious also, apart from the trouble of string building with the http request i am doing at the moment are there any performance gains of using a searcher or go the java route vs rest?

thanks for any insight or code help i can start with.

gjoranv
  • 4,376
  • 3
  • 21
  • 37
Lundin
  • 301
  • 4
  • 14

1 Answers1

2

There is an example of using the WandItem (YQL wand)here https://docs.vespa.ai/documentation/advanced-ranking.html and see also https://docs.vespa.ai/documentation/using-wand-with-vespa.html as there are two wand implementations available in Vespa, it sounds from the description that the wand() is what you want to use for this use case. For the first call you probably want to have a dedicated document summary to reduce the amount of data fetched for your first query and also the option of serving it out of memory only (See https://docs.vespa.ai/documentation/document-summaries.html)

Also see https://docs.vespa.ai/documentation/searcher-development.html as a general resource on writing searchers.

For your use case it makes a lot of sense to write a searcher to perform these two queries as your second query depends on the first and you avoid the cost of rendering/http/yql parsing which might matter if your client is remote with high network latency.

Jo Kristian Bergum
  • 2,984
  • 5
  • 8