Einen ElasticSearch – Index exportieren und importieren

Es gibt mehrere Möglichkeiten eine ElasticSearch – Index zu exportieren und wieder zu importieren. Z.B. die Möglichkeit die Gateway Snapshot API zu benutzen, das Plugin Knapsack, scan & scroll (bei Mapping-Anpassungen), oder den ElasticSearch Service auf einer Maschine herunterzufahren und per copy&paste die Files einfach auf die andere Maschine zu kopieren. Die letzte Möglichkeit stellt bei einem Index welcher nur auf einer Node läuft kein Problem dar, sollte der Index aber auf einem Cluster laufen wird es schnell „tricky“. Dann müssten z.B. alle Nodes nacheinander und mit einem Zeitpuffer heruntergefahren werden, bis auf eine Node, um dann die Index-Files von der letzten Maschine zu kopieren.

Es gibt noch eine weitere Möglichkeit, die ziemlich easy ist, vor allem wenn es nur darum geht einen Index einfach nur zu kopieren, die ich hier kurz erklären werde. Es ist  der Einsatz vom Elasticsearch-Exporter. Die Schritte erfolgen auf einem Mac, der Einsatz von Homebrew erleichtert das Ganze somit. Auf Ubuntu oder Windows könnte der Schwierigkeitsgrad steigen.

Homebrew sollte auf einem Mac nicht fehlen. Zuerst werden Node.js, Curl, NPM, Nomnom und Colors installiert:

brew install node
brew install curl
curl https://npmjs.org/install.sh | sh
npm install nomnom
npm install colors

Das Grund-Setup steht. Jetzt nur noch den Elasticsearch-Exporter auf Github auschecken, z.B. mit:
git clone https://github.com/mallocator/Elasticsearch-Exporter.git

Und dann gehts los (im ausgecheckten Ordner ausführen):

Alle Indizes von einer Maschine auf eine andere:
node exporter.js -a localhost -b otherlocalhost 

Index auf der selben Maschine kopieren:
node exporter.js -i index1 -j index2

Type kopieren innerhalb von einem Index:
node exporter.js -i index -t type1 -u type2

Type 1 vom Index 1 zu Type 2 im Index 2 kopieren:
node exporter.js -i index1 -t type1 -j index2 -u type2

Einen Index von einer auf eine andere Maschine kopieren:
node exporter.js -a localhost -i index1 -b otherlocalhost

Einen Index 1 von Maschine 1 zu einem Index 2 auf einer zweiten Maschine kopieren:
node exporter.js -a localhost -i index1 -b otherlocalhost -j index2

 

Das Kopieren erfolgt ziemlich schnell, da mit scan & scroll von ElasticSearch gearbeitet wird. Bei einer guten Leitung vergehen keine 5 Minuten bis ein Index mit 2 Millionen Dokumenten in der AWS – Cloud neu aufgebaut wurde.

 

Aus DMG wird ISO

Beim Experimentieren mit VirtualBox, auf einer Windows 7 – Maschine,  ist mir aufgefallen dass VirtualBox .DMG-Images nicht mag. Wie bekomme ich ein solches Image jetzt auf die Schnelle zum Laufen?

Nach kurzem Suchen fiel mir das ziemlich coole Tool dmg2iso in die Finger. Damit wird in kurzer Zeit aus einem .DMG-Image ein lauffähiges .ISO-Image.

So wirds gemacht:

    • dmg2iso downloaden (sourceforge.net )
    • entpacken (winrar.de)
    • Windows – Konsole starten (Hilfe)
    • In der Konsole zum entpackten dmg2iso-Ordner wechseln
      • D:
      • cd dmg2iso
    • .DMG-Image in den Ordner kopieren
      • entweder per copy&paste
      • oder in der Konsole mit move input.dmg D:/dmg2iso/.
    • ausführen
      • dmg2img input.dmg output.iso

      dmg2iso

Die output-Datei ist jetzt ein voll funktionsfähiges .ISO-Image, vorausgesetzt das .DMG-Image war fehlerfrei.

Weshalb wir Solr 4.0 genommen haben und nicht ElasticSearch

Bei einem neuen Projekt hatten wir zu entscheiden welche Search-Engine wir nehmen. Es gibt zwei führende Search-Engines auf dem Markt, ElasticSearch(0.20) und Apache Solr(4.0). Beide bauen auf Lucene auf. Nach einer Evaluation entschieden wir uns für Solr, lasst mich erklären warum.

Konditionen

Unsere Search-Engine sollte hochverfügbar und fehlertolerant sein. Sie sollte tausende vor Anfragen pro Sekunde vertragen und die Antwortzeit darf trotzdem nicht mehr als eine Sekunde betragen. Dieses Kunststück sollte auf kosten-günstigen 0815-Servern geschehen, für den Anfang. Beide Search-Engines haben dies drauf, es ist also eine schwere Entscheidung. Eine Pro&Kontra-Liste kann hier helfen.

Pro & Kontra

ProKontra
ProKontra
Solrgrößere CommunitySchema
kein Split-Brainkein Routing
Antwort in .csv, .xml, .json ...
besserer Sprachsupport out of the box
Grouping
Split shards(SOLR-3755)
Spellchecking
ElasticSearchSchema-losSplit-Brain
Routing für Indizierung & Abfragennur .json
nested documentsschlechterer Sprachsupport out of the box
multiple Dokumenttypen in einem Indexkein Grouping
Analyzer pro Dokument & Querykein Spellchecking
Percolator

Beide Search-Engines habe ihre Vorteile. Solr hat eine große Anzahl an ResponseWriters, einen sehr guten Sprachsupport und die Möglichkeit für vereinfachte Skalierung in verteilten Systemen mit SolrCloud. Andererseits wurde ElasticSearch bereits mit dem Grundgedanken für ein verteiltes und hochver-fügbares System gebaut. ElasticSearch besitzt eigentlich kein Schema, unterstützt nested documents, multiple Dokumenttypen in einem Index und hat ein großartiges Feature namens Percolator für die vorausschauende Suche. Auf der Kontra-Seite hat Solr keine Routing-Strategie wie ElasticSearch und es braucht ein Schema, aber ist es wirklich ein Nachteil mit dem Schema? ElasticSearch hat ein Problem mit der Split-Brain-Situation. Man muss .json nutzen um mit ElasticSearch zu kommunizieren, der Sprachsupport ist nicht „out of the box“ dabei sondern über Plugins, und es gibt kein Grouping oder Spellchecking.

Entscheidungspunkte

Bei unserem Projekt müssen wir wissen welche Suchfelder wir haben, also brauchen wir ein Schema. Die Dokumente sind datumsbasiert, die Anfragen an den richtigen Shard können also auch vom Frontend erfolgen über Filter die der Nutzer setzt. Wir wollen Dokumente im .csv-Format indizieren und als Ausgabe bekommen. Zentrales Konfigurationsmanagement wäre klasse. Wir wollen Nutzer sofort über neue Dokumente informieren, ein Feature wie der Percolator sollte existieren. Es sollte möglich sein die Ergebnisse zu gruppieren, und dass ist leider ein großer Nachteil von ElasticSearch, weil Grouping hier in Entwicklung ist, aber noch nicht für den Einsatz bereit steht. Ein weiterer negativer Punkt bei ElasticSearch ist die Split-Brain-Situation, wenn bei einem Netzwerkfehler ein weiterer Leader für das Cluster gewählt wird und auf einmal zwei unabhängige Cluster nebeneinander laufen. Abschliessend ist zu sagen dass wir keine „nested documents“-Funktionalität benötigen.

Zusammenfassung

Beide Search-Engines haben ihre eigenen Vorteile. Wir können Index-Mappings erstellen oder Einzeiler-Scripts in ElasticSearch benutzen um Daten im .csv-Format zu verarbeiten und es somit auf den Level von Solr zu bringen, wenn notwendig. Split-Brain-Situationen sind ein Problem, können aber auf ein Minimum reduziert werden durch vorausschauende Konfiguration. Leider brauchen wir die Grouping-Funktionalität. Solr gibt uns diese Funktionalität und es gibt keine Split-Brain-Situationen wegen dem Einsatz von Zookeeper bei SolrCloud. Die fehlende Funktionalität für Prospective-Search haben wir bereits selbst realisiert. Es war also der logische Schritt Solr zu nehmen.

Wie auch immer, hätten wir „nested documents“ benötigt, um Benutzerzugriffs-rechte auf Dokumentenebene zu ermöglichen, dann wäre die Entscheidung wohl auch zu Gunsten ElasticSearch ausgefallen.

You can read this blogpost in english here: http://www.sentric.ch/blog/why-we-chose-solr-4-0-instead-of-elasticsearch