wake-up-neo.com

Elastische Suche, mehrere Indizes gegenüber einem Index und Typen für verschiedene Datensätze?

Ich habe eine Anwendung, die mit dem MVC-Muster entwickelt wurde, und ich möchte jetzt mehrere Modelle davon indizieren, das heißt, jedes Modell hat eine andere Datenstruktur.

  • Ist es besser, mehrere Indizes zu verwenden, einen für jedes Modell oder einen Typ innerhalb des gleichen Index für jedes Modell? Beide Möglichkeiten erfordern meiner Meinung nach auch eine andere Suchanfrage. Ich habe gerade damit angefangen.

  • Gibt es leistungsbezogene Unterschiede zwischen beiden Konzepten, wenn der Datensatz klein oder groß ist?

Ich würde die 2. Frage selbst testen, wenn mir jemand einige gute Beispieldaten für diesen Zweck empfehlen könnte.

databasesearchelasticsearch
146
burzum

Beide Ansätze haben unterschiedliche Implikationen. 

Angenommen, Sie verwenden die Standardeinstellungen von Elasticsearch. Wenn Sie für jedes Modell einen Index haben, erhöht sich die Anzahl Ihrer Shards erheblich, da für einen Index 5 Shards verwendet werden, für 5 Datenmodelle 25 Shards. Während 5 Objekttypen in einem Index vorhanden sind, werden noch 5 Shards verwendet.

Auswirkungen für jedes Datenmodell als Index:

  • Effiziente und schnelle Suche innerhalb des Index, da die Datenmenge in jedem Shard geringer sein sollte, da sie auf verschiedene Indizes verteilt wird.
  • Das Durchsuchen einer Kombination von Datenmodellen aus zwei oder mehr Indizes wird Overhead generieren, da die Abfrage an mehrere Shards über Indizes hinweg gesendet, kompiliert und an den Benutzer zurückgesendet werden muss.
  • Nicht empfehlenswert, wenn Ihre Daten klein sind, da mit jedem weiteren erstellten Shard mehr Speicherplatz entsteht und der Leistungsgewinn gering ist.
  • Empfohlen, wenn Ihre Datenmenge groß ist und Ihre Abfragen sehr lange in Bearbeitung sind, da dedizierte Shards Ihre spezifischen Daten speichern und Elasticsearch einfacher zu verarbeiten ist.

Auswirkungen für jedes Datenmodell als Objekttyp innerhalb eines Index:

  • In den 5 Shards eines Index werden mehr Daten gespeichert. Dies bedeutet, dass bei der Abfrage verschiedener Datenmodelle weniger Overhead-Probleme auftreten, die Shard-Größe jedoch erheblich größer ist.
  • Wenn mehr Daten in den Shards vorhanden sind, dauert es länger, bis Elasticsearch durchsucht wird, da mehr Dokumente zum Filtern vorhanden sind.
  • Nicht empfehlenswert, wenn Sie wissen, dass Sie 1 Terabyte Daten durchlaufen und Ihre Daten nicht auf verschiedene Indizes oder mehrere Shards in Ihrer Elasticsearch-Zuordnung verteilen.
  • Empfohlen für kleine Datensätze, da Sie keinen Speicherplatz für geringfügige Leistungssteigerungen verschwenden, da jeder Shard Platz in Ihrer Hardware beansprucht.

Wenn Sie fragen, was ist zu viel Daten gegenüber kleinen Daten? Normalerweise hängt es von der Prozessorgeschwindigkeit und dem RAM Ihrer Hardware ab, von der Datenmenge, die Sie in jeder Variablen in Ihrem Mapping für Elasticsearch speichern, und von Ihren Abfrageanforderungen. Durch die Verwendung vieler Facetten in Ihren Abfragen wird Ihre Antwortzeit erheblich verlangsamt. Es gibt keine einfache Antwort darauf und Sie müssen entsprechend Ihren Bedürfnissen Benchmarking durchführen.

174
Jonathan Moo

Obwohl Jonathans Antwort zu dieser Zeit korrekt war, hat sich die Welt weiterentwickelt und es scheint, dass die Leute hinter ElasticSearch einen langfristigen Plan haben, die Unterstützung für mehrere Typen einzustellen:

Wohin wollen wir: Wir möchten das Konzept der Typen von Elasticsearch entfernen und dabei Eltern/Kinder unterstützen.

Wenn Sie also nur einen einzigen Typ pro Index verwenden, wird die Aktualisierung auf ElasticSearch 6.x für neue Projekte einfacher.

36
Danack

Jonathans Antwort ist großartig. Ich möchte nur ein paar andere Punkte hinzufügen:

  • die Anzahl der Shards kann für jede von Ihnen ausgewählte Lösung angepasst werden. Sie haben möglicherweise einen Index mit 15 primären Shards oder teilen ihn für 5 Shards in 3 Indizes auf. Die Leistungsperspektive ändert sich nicht (vorausgesetzt, die Daten sind gleichmäßig verteilt).
  • denken Sie über die Datennutzung nach. Ie. Wenn Sie Kibana für die Visualisierung verwenden, ist es einfacher, bestimmte Indizes ein- oder auszuschließen. Die Typen müssen jedoch im Dashboard gefiltert werden
  • datenaufbewahrung: Verwenden Sie für Anwendungsprotokoll-/Metrikdaten unterschiedliche Indizes, wenn Sie einen anderen Aufbewahrungszeitraum benötigen
13
Marcel Matus

Die beiden obigen Antworten sind großartig! 

Ich füge ein Beispiel für mehrere Typen in einem Index hinzu. Angenommen, Sie entwickeln eine App, um nach Büchern in einer Bibliothek zu suchen. Es gibt einige Fragen, die Sie dem Bibliotheksbesitzer stellen müssen.

Fragen:

  1. Wie viele Bücher möchten Sie einlagern?

  2. Welche Bücher werden Sie in der Bibliothek aufbewahren? 

  3. Wie suchst du nach Büchern?

Antworten:

  1. Ich habe vor, 50 bis 70 k Bücher zu speichern (ungefähr)

  2. Ich werde über 15 -20-k-technische Bücher (Informatik, Maschinenbau, Chemieingenieurwesen usw.), 15.000 historische Bücher, 10.000 medizinische Bücher verfügen. 10 k von sprachbezogenen Büchern (Englisch, Spanisch usw.) 

  3. Suche nach Autoren, Vorname, Name des Verfassers, Erscheinungsjahr, Name des Herausgebers. (Dies gibt Ihnen die Idee, welche Informationen Sie im Index speichern sollten.)

Aus den obigen Antworten können wir sagen, dass das Schema in unserem Index so aussehen sollte.

// Dies ist nicht die genaue Zuordnung, nur für das Beispiel 

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Um dies zu erreichen, können wir einen Index namens Books erstellen und verschiedene Typen haben.

Index: Buch

Typen: Wissenschaft, Kunst

(Oder Sie können viele Arten erstellen, z. B. Technologie, Medizin, Geschichte, Sprache, wenn Sie viel mehr Bücher haben.)

Beachten Sie hierbei, dass das Schema ähnlich ist, die Daten jedoch nicht identisch sind. Und die andere wichtige Sache ist die Gesamtdatenmenge, die Sie speichern. 

Hoffen Sie, dass die oben genannten Punkte hilfreich sind, wenn Sie sich für verschiedene Typen in einem Index entscheiden. Wenn Sie ein anderes Schema verwenden, sollten Sie einen anderen Index in Betracht ziehen. Kleiner Index für weniger Daten. großer Index für Big Data :-)

0
Sourav