Haben Sie gerade das Schema für Ihren Solr-Index geändert und können das neue Schema nicht mit Ihren vorhandenen Daten und Dokumenten verwenden? Oder haben Sie einen neuen Index mit mehr Shards und besserem Routing erstellt und müssen Ihre Daten in diesen neuen Index verschieben? Oder haben Sie eine neue Infrastruktur mit besserer Hardware aufgebaut und möchten Ihre Sammlungen samt Daten auf die neuere Infrastruktur verlagern? Ein Re-Indexing ist die Antwort auf Ihre Fragen.
Im Gegensatz zu Elasticsearch ist das Re-Indexing in Apache Solr leider nicht als Funktion vorgesehen. Es gab eine Zeit, in der Sie den Datenimport-Handler (DIH) verwenden konnten, um mit Hilfe eines Skripts ein Re-Indexing durchzuführen, aber DIH werden von Apache Solr nicht mehr offiziell unterstützt. Um Ihre Daten zuverlässig von einer Sammlung in eine andere zu verschieben, ist das Schreiben eines eigenen Skripts und die Optimierung dieses Skripts der einfachste und schnellste Weg, diese Herausforderung zu lösen.
Die Idee, Daten von einer Sammlung oder einem Index in einen anderen neu zu indizieren, scheint so einfach zu sein, als würden die Dokumente einzeln aus dem Quellindex geholt und an den neuen Zielindex gesendet. Allerdings gibt es beim Re-indexing kleine aber entscheidende Details, die unbedingt beachtet werden müssen. Besonders wenn es sich um zig Millionen Dokumente handelt, kann das Verschieben entmutigend sein und das Fehlen eines kleinen Details kann viel Zeit und Ressourcen kosten.
In diesem Artikel veranschaulichen wir das Re-indexing in Solr und zeigen alle Details, die Sie im Auge behalten müssen. Dazu gehen wir von einem Szenario aus, in dem wir das Schema des Index geändert und einen neuen Index mit diesem neuen Schema erstellt haben und nun Dokumente aus der alten Sammlung in die neue Sammlung neu indizieren möchten. Der Quellindex umfasst etwa 5 Millionen Dokumente. Wir haben in jedem Dokument mehrere Attribute. Um das Re-indexingsskript zu schreiben werden wir Python verwenden, da es eine „Pysolr“-Bibliothek enthält, mit der problemlos Anfragen an Solr-Instanzen gestellt werden können.
Inhaltsverzeichnis
Vorbereitungen
Zunächst müssen wir sicherstellen, dass genügend Platz für den neuen Index verfügbar ist. Falls es sich auf derselben oder einer neuen Infrastruktur befindet, sollte mindestens so viel Speicherplatz verfügbar sein, wie bereits belegt ist. Sie können dies überprüfen, indem Sie zum Solr-Dashboard gehen und dann im Abschnitt „Cloud“ auf „Knoten“ klicken. Hier in den Details können Sie sehen, wie viel Platz jede Sammlung auf jedem Knoten verbraucht. Das Zweite, was überprüft werden muss, ist das Netzwerk. Da der Re-indexingsprozess lange dauern kann, ist es wichtig, dass die Kommunikation zwischen dem Skript und der Solr-Instanz nicht unterbrochen wird. Ideal wäre es, das Skript im selben Netzwerk wie die Solr-Instanz auszuführen, da dies aufgrund geringer Netzwerkverzögerungen auch die Re-indexingsgeschwindigkeit verbessert.
Reihenfolge der Re-indexing
Es gibt zwei Arten von Sammlungen, die neu indiziert werden könnten. Ein Typ enthält statische Daten, die überhaupt nicht geändert werden, und der zweite Typ enthält Live-Daten, die regelmäßig aktualisiert werden. Wenn es sich um einen Index mit statischen Daten handelt, ist die Sache viel einfacher. Hier kann man die eindeutigen IDs verwenden, um Daten sequenziell von einem Index zum anderen zu verschieben.
Viel komplizierter wird es jedoch, wenn Sie mit einem Index arbeiten, der während des Re-indexingsprozesses aktualisiert wird. Für dieses Szenario benötigen wir ein Referenzattribut, das zur Identifizierung aktualisierter oder aktueller Dokumente verwendet werden kann. Idealerweise sollten die Dokumente über ein Datumsfeld verfügen. Dies könnte ein Feld „createdDate“ oder „lastUpdated“ sein. Das Feld „lastUpdated“ trägt dazu bei, dass die Re-indexing wesentlich genauer wird. Dadurch behalten Sie den Überblick über die neuesten Dokumente. Sobald die Hauptindizierung abgeschlossen ist, müssen Sie nur noch die neuesten Dokumente neu indizieren, die in den letzten Minuten eingegangen sind.
Auch hier gilt es zu beachten, dass bei der Verwendung von Datumsangaben die Zeitzonen berücksichtigt werden sollten. Möglicherweise unterscheidet sich die Zeitzone auf der Solr-Instanz von der Zeitzone auf der Instanz, auf der das Skript ausgeführt wird.
Vorverarbeitung
Nachdem Sie die Dokumente aus dem Quellindex erhalten haben, müssen Sie höchstwahrscheinlich einige Anpassungen an den Dokumenten vornehmen, bevor Sie sie an den neuen Index senden. Eine Änderung, die Sie unbedingt vornehmen müssen, besteht darin, das Attribut „_version_“ aus den Dokumenten zu entfernen. Es handelt sich um ein von Solr reserviertes Attribut, und Solr lehnt Dokumente ab, die dieses Attribut enthalten. Und falls Sie den Typ eines Attributs geändert haben, müssen Sie dies auch im Skript berücksichtigen. Sie haben beispielsweise ein Attribut im neuen Schema entfernt oder den Typ eines Attributs von String in Integer geändert.
Bulk-Processing
Wenn wir beginnen, Dokumente einzeln aus einer Sammlung abzurufen und an eine neue Sammlung zu senden, während sich Millionen von Dokumenten im Quellindex befinden, kann es Monate dauern, bis wir das Re-Indexing abgeschlossen haben. Um dieses Problem zu lösen, müssen wir die von Solr bereitgestellte BULK-Indizierungsfunktion nutzen. Wir müssen jedoch darauf achten, nicht 100.000 Dokumente in einer einzigen Anfrage zu senden, da dies zu Netzwerk- und Zeitüberschreitungsproblemen führen kann. Für statische Daten können, wie bereits erwähnt, die UUID/eindeutigen IDs verwendet werden, um Datenblöcke ähnlicher Größe zu erstellen. Unter der Annahme, dass die UUID-Ziffern Werte im Bereich von 0,1,2,3,4…9,a,b,c,d,e,f haben können, wäre es klug, alle Dokumente mit UUIDs mit 0000 beginnen zu lassen und dann alle Dokumente beginnen mit 0001 und dann 0002 und so weiter und so weiter. Hier gehen wir davon aus, dass die Anzahl der Dokumente, die mit 0000 oder 0001 beginnen, im Durchschnitt etwa 1000–5000 Dokumente beträgt. Wenn es noch viel mehr ist, könnten Sie mit 00000 und dann 00001 beginnen.
Im Fall von Live-Daten und wenn Datumsangaben zur Erstellung von Blöcken verwendet werden, könnte man Blöcke für jede Stunde, jeden Tag oder jede Woche erstellen, je nachdem, wie viele Dokumente für jede Stunde, jeden Tag oder jede Woche vorhanden sind. Idealerweise sollte die Anzahl bei etwa 1000 bis 5000 Dokumenten liegen.
Abschluss
Ein Re-Indexing in Solr kann schwierig sein, ist aber möglich. Funktionen wie die Verwendung von Filter-Abfragen zum Suchen und Teilen von Daten und die Verwendung des Bulk-Indexing können den Prozess exponentiell beschleunigen. Ein weiterer Tipp besteht darin, zunächst eine Testsammlung zu erstellen und einen Unterabschnitt der Dokumente neu zu indizieren. Sie können diesen Index zunächst testen und prüfen, ob er die Anforderungen erfüllt und alle Dokumente, die ein Kriterium erfüllen, erfolgreich indiziert wurden oder nicht. Ein Beispielskript zur Re-Indexierung eines Live-Index finden Sie hier.
