Datenverlustfreie ElasticSearch-Datenmigration


    Beim Design eines Academic Data Warehouse wird empfohlen, alles in normalisierter Form und mit Links zwischen ihnen zu speichern. Durch die Aktualisierung von relationalen Berechnungen wird ein zuverlässiges Repository mit Transaktionsunterstützung bereitgestellt. Atomizität, Konsistenz, Isolation, Haltbarkeit - das ist alles. Mit anderen Worten, der Speicher ist speziell dafür konzipiert, Daten sicher zu aktualisieren. Es ist jedoch nicht optimal für die Suche, vor allem mit einer breiten Geste auf den Tabellen und Feldern. Auf der Suche nach Indizes, vielen Indizes. Volumes werden erweitert, die Aufnahme verlangsamt sich. SQL LIKE wird nicht indiziert und JOIN GROUP BY sendet, um im Abfrageplaner zu meditieren.


    Die zunehmende Belastung einer Maschine zwingt sie dazu, sich entweder vertikal in die Decke oder horizontal auszudehnen, indem mehrere Knoten gekauft werden. Anforderungen an die Ausfallsicherheit bewirken, dass Daten auf mehrere Knoten verteilt werden. Die Forderung nach einer sofortigen Wiederherstellung nach einem Fehler ohne Diensteverweigerung zwingt uns dazu, einen Cluster von Maschinen einzurichten, so dass jeder von ihnen jederzeit schreiben und lesen kann. Das heißt, bereits ein Meister zu sein oder sie automatisch und sofort zu werden.


    Das Problem der Schnellsuche wurde durch die Installation einer Reihe von zweiten für die Indizierung optimierten Speichern gelöst. Volltextsuche, facettiert, mit Stemmingund Blackjack. Der zweite Speicher akzeptiert Datensätze aus der ersten Tabelle als Eingabe, analysiert und erstellt einen Index. Daher wurde der Datenspeicherungscluster für ihre Suche um einen weiteren Cluster ergänzt. Mit einer ähnlichen Master-Konfiguration, die der Gesamt- SLA entspricht . Alles ist gut, das Geschäft ist begeistert, die Admins schlafen nachts ... bis die Maschinen im Master-Master-Cluster mehr als drei sind.


    Elastisch


    Die NoSQL- Bewegung hat den Skalierungshorizont sowohl für kleine als auch für große Daten erheblich erweitert. NoSQL-Clusterknoten sind in der Lage, Daten untereinander zu verteilen, sodass der Ausfall eines oder mehrerer Knoten nicht zu einem Denial-of-Service für den gesamten Cluster führt. Der Preis für die hohe Verfügbarkeit verteilter Daten war die Unmöglichkeit, zu jedem Zeitpunkt eine vollständige Konsistenz der Daten zu gewährleisten. Stattdessen spricht NoSQL von einer eventuellen Konsistenz . Das heißt, es wird angenommen, dass, sobald alle Daten über die Clusterknoten verteilt sind, sie letztendlich konsistent werden.


    Daher wurde das relationale Modell durch ein nicht relationales Modell ergänzt und führte zu vielen Datenbank-Engines, die die Probleme des CAP- Dreiecks mit dem einen oder anderen Erfolg lösen . Die Entwickler hatten modische Werkzeuge in die Hand, um ihre eigene perfekte Persistenzschicht zu erstellen - für jeden Geschmack, jedes Budget und jedes Lastprofil.


    ElasticSearch ist ein Vertreter von Cluster NoSQL mit RESTful-JSON-API in der Lucene-Engine, Open Source in Java, die nicht nur einen Suchindex erstellen kann, sondern auch das Originaldokument speichern kann. Ein solcher Trick hilft, die Rolle eines separaten Datenbankverwaltungssystems für das Speichern der Originale zu überdenken oder sogar ganz aufzugeben. Das Ende des Eintrags


    Zuordnung


    Das Mapping in ElasticSearch ist so etwas wie ein Schema (Tabellenstruktur in SQL-Begriffen), das Ihnen genau beschreibt, wie eingehende Dokumente (Datensätze, in SQL-Begriffen) indiziert werden sollen. Die Zuordnung kann statisch, dynamisch oder nicht vorhanden sein. Statisches Mapping lässt sich nicht ändern. Mit Dynamic können Sie neue Felder hinzufügen. Wenn keine Zuordnung festgelegt wurde, erstellt ElasticSearch das erste Dokument, das geschrieben werden soll. Analysieren Sie die Struktur der Felder, machen Sie einige Annahmen über die Datentypen, überspringen Sie die Standardeinstellungen und schreiben Sie. Auf den ersten Blick erscheint ein solches verhaltensloses Verhalten sehr günstig. Tatsächlich aber eher für Experimente geeignet als für Überraschungen in der Produktion.


    Die Daten werden also indiziert und dies ist ein unidirektionaler Prozess. Nach dem Erstellen kann das Mapping nicht dynamisch als ALTER TABLE in SQL geändert werden. Weil die SQL-Tabelle das Originaldokument speichert, auf das Sie den Suchindex schrauben können. Und in ElasticSearch das Gegenteil. Er selbst ist ein Suchindex, an dem Sie das Originaldokument befestigen können. Deshalb ist das Indexschema statisch. Theoretisch könnte man entweder ein Feld im Mapping erstellen oder es löschen. In der Praxis können Sie in ElasticSearch jedoch nur Felder hinzufügen. Der Versuch, ein Feld zu löschen, führt zu nichts.


    Alias


    Der Alias ​​ist dieser optionale Name für den ElasticSearch-Index. Aliase können für einen einzelnen Index mehrere sein. Oder ein Alias ​​für mehrere Indizes. Dann scheinen die Indizes logisch miteinander verbunden zu sein und sehen von außen gleich aus. Alias ​​ist sehr praktisch für Services, die während ihrer gesamten Lebensdauer mit dem Index kommunizieren. Zum Beispiel kann das Pseudonym von Produkten sowohl products_v2 als auch products_v25 hinter sich verbergen , ohne dass die Namen im Service geändert werden müssen. Alias ​​ist für die Datenmigration unverzichtbar, wenn sie bereits vom alten Schema in das neue Schema übertragen werden und Sie die Anwendung wechseln müssen, um mit dem neuen Index zu arbeiten. Das Umschalten eines Alias ​​von Index auf Index ist eine atomare Operation. Das heißt, es wird in einem Schritt ohne Verlust ausgeführt.


    API neu indizieren


    Das Datenschema, das Mapping, ändert sich von Zeit zu Zeit. Neue Felder werden hinzugefügt, nicht benötigte Felder werden gelöscht. Wenn ElasticSearch die Rolle eines einzelnen Repositorys spielt, benötigen Sie ein Werkzeug, um das Mapping im laufenden Betrieb zu ändern. Dafür gibt es einen speziellen Befehl zum Übertragen von Daten von einem Index auf einen anderen, die sogenannte _reindex-API . Es arbeitet mit einer fertigen oder leeren Zuordnung des Empfängerindex auf der Serverseite, wodurch in Stapeln von 1000 Dokumenten gleichzeitig indiziert wird.


    Durch Neuindizierung kann eine einfache Feldtypkonvertierung durchgeführt werden. Zum Beispiel lang in Text und zurück in lang oder boolean in Text und zurück in boolean . Aber -9,99 in Boolean ist nicht mehr in der Lage,das ist kein PHP. Andererseits ist die Typumwandlung eine unsichere Sache. Dienst, geschrieben in einer Sprache mit dynamischer Typisierung wie eine Sünde, vielleicht verzeihen. Wenn der Index jedoch nicht konvertiert werden kann, wird das Dokument einfach nicht aufgezeichnet. Im Allgemeinen sollte die Datenmigration in drei Schritten erfolgen: Ein neues Feld hinzufügen, einen Dienst freigeben, das alte bereinigen.


    Ein Feld wird so hinzugefügt. Das Quellindexschema wird übernommen, eine neue Eigenschaft passt, ein leerer Index wird erstellt. Dann wird die Neuindizierung gestartet:


    {
      "source": {
        "index": "test"
      },
      "dest": {
        "index": "test_clone"
      }
    }

    Entfernt das Feld auf ähnliche Weise. Das Quellindexschema wird übernommen, das Feld wird entfernt und ein leerer Index wird erstellt. Anschließend wird die Neuindizierung mit der Liste der kopierten Felder gestartet:


    {
      "source": {
        "index": "test",
        "_source": ["field1", "field3"]
      },
      "dest": {
        "index": "test_clone"
      }
    }

    Beide Fälle werden in Kaizen, dem Desktop-Client für ElasticSearch, zur Klonfunktion zusammengefasst. Das Klonen kann sich an die Abbildung des Empfängerindex anpassen. Das folgende Beispiel zeigt, wie ein partieller Klon aus einem Index mit drei Sammlungen (Typen in Bezug auf ElasticSearch) act , line , scene erstellt wird . Es bleibt nur noch eine Zeile mit zwei Feldern, die statische Zuordnung ist aktiviert , und das Feld speech_number aus Text wird lang .



    Migration


    Die Reindex-API hat eine unangenehme Funktion - sie weiß nicht, wie sie Änderungen im Quellindex überwacht. Wenn sich nach dem Beginn der Neuindizierung dort etwas ändert, werden die Änderungen nicht im Empfängerindex angezeigt. Um dieses Problem zu lösen, wurde das ElasticSearch FollowUp Plugin entwickelt, das Protokollierungsbefehle hinzufügt. Das Plugin kann dem Index folgen und die Aktionen, die für Dokumente in chronologischer Reihenfolge ausgeführt werden, im JSON-Format zurückgeben. Der Index, der Typ, die Dokument-ID und die Operation darauf - INDEX oder DELETE werden gespeichert. Das FollowUp Plugin ist auf GitHub veröffentlicht und wird für fast alle Versionen von ElasticSearch kompiliert.


    Für die verlustfreie Datenmigration benötigen Sie daher ein FollowUp, das auf dem Knoten installiert ist, auf dem die Neuindizierung gestartet wird. Es wird davon ausgegangen, dass der Aliasindex bereits verfügbar ist und alle Anwendungen durchlaufen. Unmittelbar vor der Neuindizierung ist das Plugin aktiviert. Wenn die Neuindizierung abgeschlossen ist, wird das Plugin deaktiviert und der Alias ​​wird in einen neuen Index übertragen. Dann werden die aufgezeichneten Aktionen auf dem Empfängerindex reproduziert, um ihren Status einzuholen. Trotz der hohen Geschwindigkeit der Neuindexierung können zwei Arten von Kollisionen während der Wiedergabe auftreten:


    • Im neuen Index gibt es kein Dokument mehr mit einer solchen _id . Es gelang ihnen, das Dokument zu löschen, nachdem der Alias ​​auf den neuen Index umgestellt wurde.
    • Im neuen Index befindet sich ein Dokument mit der gleichen _id , jedoch mit einer höheren Versionsnummer als im Quellindex . Es gelang ihnen, das Dokument zu aktualisieren, nachdem das Pseudonym auf den neuen Index umgestellt wurde.

    In diesen Fällen sollte die Aktion nicht im Empfängerindex abgebildet werden. Die restlichen Änderungen werden wiedergegeben.


    Viel Spaß beim Codieren!


    Jetzt auch beliebt: