[UPDATE] Räumliche Suche in Apache Lucene und Solr
Eine der häufigsten Fragen, die ich gestellt bekomme, lautet: „Wie sieht es mit Spatial in Lucene und Solr aus?“ Hier ist also meine Antwort von heute:
- Ich habe neulich SOLR-1568 übergeben, das die automatische Filtergenerierung für die verschiedenen punktbasierten Feldtypen in Solr hinzufügt. Außerdem wurde der zugrunde liegende Lucene-Code ein wenig umgestaltet. Außerdem wird ein neuer LatLonType hinzugefügt, mit dem sich Breiten-/Längengradpaare nahtlos darstellen lassen. Unter http://wiki.apache.org/solr/SpatialSearch finden Sie alle Details zu Solr Spatial. Bitte beachten Sie, dass dies nur auf Trunk verfügbar ist. Freiwillige, die eine Rückportierung auf 3.x vornehmen möchten, sind herzlich willkommen.
- Im Rahmen von SOLR-1568 wurde mir immer klarer, dass die kartesische Ebene in Lucene Spatial für viele, viele Dinge einfach nicht wie vorgesehen funktioniert. Bei meiner Überprüfung und meinem Versuch, den Code zu reparieren, wurde mehr als deutlich, dass er nur für die westliche Hemisphäre oberhalb des Äquators, d.h. für die Vereinigten Staaten, funktioniert. Möglicherweise funktioniert er auch in der östlichen Hemisphäre über dem Äquator. Der Grund dafür, dass es nur oberhalb des Äquators funktioniert, liegt in einem Rechenfehler im SinusoidalProjector. Siehe LUCENE-2519. Der SinusoidProjector kann auch nicht gut mit Randfällen umgehen, wie z.B. an den Polen oder den Null- und Nullmeridianen. Ich habe den SinusoidalProjector nicht repariert, weil er zu einem sehr verworrenen Netz von fehlerhaften Unit-Tests wurde. In Gesprächen mit anderen Entwicklern haben wir beschlossen, dass das gesamte Tier-System (und ein Großteil der räumlichen Struktur von Lucene) veraltet/ersetzt werden sollte.
Ich glaube, Trunk ist jetzt in einem ziemlich guten Zustand für die räumliche Suche für Anwendungen, die dies benötigen:
- Sortieren nach Entfernung
- Boosting durch Entfernung
- Bereichsabfrage (mit numerischen Feldern) basierte Bounding-Box-Berechnungen, die für die meisten Benutzer ausreichend sein sollten
- Geohash-basierte Berechnungen
Trunk verfügt noch nicht über die Fähigkeit dazu:
- Pseudofelder zur Ergebnismenge hinzufügen, so dass es nicht möglich ist, die Entfernung in die Ergebnismenge aufzunehmen, wie andere gespeicherte Felder
- Ein auf Ebenen/Kacheln/Gittern basierender Ansatz zum Filtern. Diese Ansätze sind besonders in sehr dichten Gebieten hilfreich, da sie die Anzahl der Begriffe, die aufgezählt werden müssen, erheblich reduzieren können
- Facettierung nach Funktionen, die nützlich sein kann, um Entfernungen in Bereiche einzuteilen, wie z.B.: zu Fuß gehen, mit dem Fahrrad fahren, Auto fahren
Eine Liste aller mit Solr/Lucene verbundenen räumlichen Probleme finden Sie unter SOLR-773. Auch hier finden Sie unter http://wiki.apache.org/solr/SpatialSearch eine vollständige Übersicht über den Inhalt von Solr und dessen Verwendung.
Zusammenfassend denke ich, dass Trunk in Bezug auf Solr in einer ziemlich guten Verfassung ist, wenn es um Spatial geht. Reine Lucene-Benutzer werden in den kommenden Monaten einige Umwälzungen erleben, aber das ist gut so. Tester werden gebraucht und Patches sind willkommen. Und auch wenn sich das Tier-Zeug wie ein Rückschritt anfühlt, ist mir klar, dass wir mehrere Committer und viele Mitwirkende haben, die sehr daran interessiert sind, dass die Spatial-Unterstützung lebt und gedeiht.