Mehrwertige Geolokalisierungsfelder in Solr

Heute sehen wir uns einen kleinen Workaround an, mit dem Sie einen sehr häufigen Anwendungsfall der geografischen Suche lösen können.…

Heute sehen wir uns einen kleinen Workaround an, mit dem Sie einen sehr häufigen Anwendungsfall der geografischen Suche lösen können.

Der Anwendungsfall sieht folgendermaßen aus

Der Kunde ist in Buenos Aires ansässig und möchte eine lila Krawatte

Er gibt die Suchanfrage „lila Krawatte“ in das Suchfeld auf der Webseite des Shops ein.

Das System gibt die Krawatten zurück, die in den Geschäften in der Nähe von Buenos Aires gekauft werden können, und dann in unseren Geschäften in Montevideo (d.h. Krawatten, die in den Geschäften in der Nähe gefunden werden können)

Das heißt, das System liefert keine Krawatten in unseren Geschäften in Spanien, weil niemand nach Spanien reisen würde, um eine Krawatte zu kaufen, und auch niemand eine Krawatte über den Atlantik bestellen würde (keine Krawatte ist so speziell). Dies ist Teil des ersten und wahrscheinlich einzigen Problems von Suchsystemen: nur relevante Ergebnisse liefern. In diesem Fall relevant im Hinblick auf ihren Standort.

Theoretisch ließe sich das Problem leicht mit einem mehrwertigen Koordinatenfeld lösen, in dem jede Verbindung (oder jedes Produkt in unserem System) eine Liste von Koordinaten hat, in der sich diese Verbindung befindet. Wir würden unsere Produkte in einem Kreis mit dem Mittelpunkt Buenos Aires filtern, um die Produkte in der Nähe zu erhalten.

Das funktioniert gut, wenn das Produkt nur in einem Geschäft erhältlich ist, aber wenn es an mehreren Orten gleichzeitig erhältlich ist (d.h. es gibt eine Liste von Koordinaten im Feld, nicht nur eine einzige), tritt das Problem auf. Es kommt vor, dass Solr das Filtern nach mehrwertigen Koordinatenfeldern nicht zulässt.

Aber es ist noch nicht alles verloren, und in diesem Beitrag schlage ich eine Lösung für dieses Problem vor.

Wir werden einen weiteren Index erstellen, der nur die Stores, ihre ID und ihren Standort enthält. Mit einem Pseudocode im C-Stil können wir dies als ein Dokument in unserem „Stores Index“ betrachten

struct {
latlon location;
int storeID;
} store;

Mit diesem anderen Index (z.B. einem anderen Solr Core) werden wir unsere Abfrage in zwei Teile aufteilen:

1- Für die erste Abfrage werden Sie den „Filialindex“ abfragen. Sie führen eine geografische Filterabfrage durch (unter Verwendung der räumlichen Solr-Funktionalität) und erhalten eine Liste der Laden-IDs in der Nähe des von Ihnen angegebenen zentralen Punktes. In dieser Phase haben Sie die vom Benutzer eingegebene Abfrage noch nicht verwendet, sondern nur den Standort des Benutzers, der auf irgendeine Weise ermittelt wurde.

q=*:*&fl=storeID&fq={!geofilt pt=-34.60,-58.37 sfield=location d=5}

Und Sie erhalten eine Liste der Speicher-IDs

id=34, id=56, id=77

2 – In der zweiten Phase führen Sie die Abfrage (jetzt mit der vom Benutzer eingegebenen Abfrage) auf die übliche Art und Weise durch, fügen aber eine Filterabfrage hinzu (eine reguläre Filterabfrage, keine geografische), und zwar folgendermaßen:

q=”product brand x”&fq=(storeId:34 OR storeId:56 OR storeId:77)

wobei die Laden-IDs diejenigen sind, die von der ersten Abfrage zurückgegeben wurden und folglich in der Nähe des zentralen Punktes liegen.

In diesem Fall beschränken Sie Ihre Ergebnisse auf diejenigen, die sich in der Nähe des Nutzers befinden. Sie können auch die nächstgelegenen Ergebnisse verstärken, aber auch die weiter entfernten auf den erweiterten Seiten der Ergebnisse anzeigen.

Zusammenfassend lässt sich sagen, dass wir zwei Abfragen mit regulären Funktionen verwenden, um die von Ihnen gewünschten erweiterten Funktionen zu erhalten. Die erste Abfrage ermittelt die Geschäfte in der Nähe der Zone, und die zweite ist die eigentliche Abfrage.

Es gibt einen Patch in der Entwicklung, der die gleiche Funktionalität bietet SOLR-2155, aber er wurde noch nicht commited. In der Zwischenzeit haben Sie hier ein gutes Beispiel dafür, was Sie mit mehreren Abfragen an Solr machen können.

Quelle: mein Blog!

UPDATE (von Hoss)

Diese Art des logischen Ablaufs geht weit über die geobasierte Suche hinaus, und mit dem neuen „Join“-QParser, der in Solr 4.x verfügbar sein wird, brauchen Sie keinen eigenen Index (oder eine zweite Abfrage), um solche Dinge zu tun.

Sie können Ihre „Store“-Dokumente in denselben Index wie Ihre „Product“-Dokumente aufnehmen und sie miteinander verknüpfen, ala…

q=“Produktmarke x“&fq={!join from=id to=storeId v=$loc}&loc={!geofilt pt=-34.60,-58.37 sfield=location d=5}

Sehen Sie sich das Wiki für weitere Details an…

https://wiki.apache.org/solr/Join

You Might Also Like

Analytics Studio: Verwandeln Sie Ihre E-Commerce-Daten in verwertbare Einblicke

Entdecken Sie, wie Analytics Studio Teams in die Lage versetzt, datengestützte Entscheidungen...

Read More

Wenn KI schief geht: Fehlschläge in der realen Welt und wie man sie vermeidet

Lassen Sie nicht zu, dass Ihr KI-Chatbot einen 50.000 Dollar teuren Tahoe...

Read More

Lucidworks Kernpakete: Branchenoptimierte KI-Such- und Personalisierungslösungen

Entdecken Sie unsere umfassenden Core Packages, die Analytics Studio, Commerce Studio und...

Read More

Quick Links

Diese Site ist auf wpml.org als Entwicklungssite registriert. Wechseln Sie zu einer Produktionssite mit dem Schlüssel remove this banner.