Elasticsearch
Unterschied zwischen Indizes und Typen

Es ist leicht, type wie eine Tabelle in einer SQL-Datenbank zu sehen, wobei der index die SQL-Datenbank ist. Dies ist jedoch keine gute Möglichkeit, sich dem type s zu nähern.

Alles über Typen

Tatsächlich sind Typen buchstäblich nur ein Metadatenfeld, das jedem Dokument von Elasticsearch hinzugefügt wird: _type . In den obigen Beispielen wurden zwei Typen erstellt: my_type und my_other_type . Das bedeutet, dass jedes Dokument, das den Typen zugeordnet ist, ein zusätzliches Feld hat, das automatisch wie "_type": "my_type" ; Dieses Dokument wird mit dem Dokument indiziert, wodurch es zu einem durchsuchbaren oder filterbaren Feld wird. Es hat jedoch keine Auswirkungen auf das Rohdokument selbst, sodass sich Ihre Anwendung nicht darum kümmern muss.

Alle Typen leben in demselben Index und daher in denselben gemeinsamen Shards des Index. Selbst auf der Festplattenebene leben sie in den gleichen Dateien. Die einzige Trennung, die das Erstellen eines zweiten Typs bietet, ist eine logische. Jeder Typ, unabhängig davon, ob er eindeutig ist oder nicht, muss in den Mappings vorhanden sein, und alle diese Mappings müssen in Ihrem Clusterstatus vorhanden sein. Dies frisst Speicher und wenn jeder Typ dynamisch aktualisiert wird, nimmt die Leistung ab, wenn sich die Zuordnungen ändern.

Daher empfiehlt es sich, nur einen einzigen Typ zu definieren, es sei denn, Sie benötigen tatsächlich andere Typen. Es werden häufig Szenarien angezeigt, in denen mehrere Typen wünschenswert sind. Stellen Sie sich beispielsweise vor, Sie hätten einen Autoindex. Es kann für Sie nützlich sein, es mit mehreren Typen aufzuschlüsseln:

• BMW
• chevy
• Honda
• Mazda
• Mercedes
• Nissan
• Rangerover
• Toyota
• ...

Auf diese Weise können Sie nach allen Fahrzeugen suchen oder sie nach Hersteller einschränken. Der Unterschied zwischen diesen beiden Suchen ist so einfach:

GET /cars/_search

und

GET /cars/bmw/_search

Was für neue Benutzer von Elasticsearch nicht offensichtlich ist, ist, dass die zweite Form eine Spezialisierung der ersten Form ist. Es wird buchstäblich umgeschrieben in:

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

Es filtert einfach alle Dokumente heraus, die nicht mit einem _type Feld mit dem Wert bmw . Da jedes Dokument mit seinem Typ als _type Feld indiziert wird, dient dies als ziemlich einfacher Filter. Wenn in einem der Beispiele eine tatsächliche Suche bereitgestellt wurde, wird der Filter entsprechend der vollständigen Suche hinzugefügt.

Wenn also die Typen identisch sind, ist es viel besser, einen einzigen Typ (z. B. manufacturer in diesem Beispiel) bereitzustellen und ihn effektiv zu ignorieren. Geben Sie dann in jedem Dokument explizit ein Feld mit dem Namen make oder einen beliebigen Namen an und filtern Sie es manuell, wann immer Sie es einschränken möchten. Dadurch wird die Größe Ihrer Zuordnungen auf 1/n reduziert, wobei n die Anzahl der separaten Typen ist. Es fügt jedem Dokument ein weiteres Feld hinzu, da sonst die Zuordnung vereinfacht wird.

In Elasticsearch 1.x und 2.x sollte ein solches Feld als definiert werden

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}

1. Der Name ist beliebig.
2. Der Name ist beliebig und könnte mit dem Typnamen übereinstimmen, wenn Sie es auch wollten.

In Elasticsearch 5.x funktioniert das oben immer noch (es ist veraltet), aber der bessere Weg ist zu verwenden:

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}

1. Der Name ist beliebig.
2. Der Name ist beliebig und könnte mit dem Typnamen übereinstimmen, wenn Sie es auch wollten.

Typen sollten in Ihren Indizes sparsam verwendet werden, da sie die Indexzuordnungen aufblähen, normalerweise ohne großen Nutzen. Sie müssen mindestens eine haben, aber es gibt nichts, was besagt, dass Sie mehr als eine haben müssen.

Häufige Fragen

• Was ist, wenn ich zwei (oder mehr) Typen habe, die größtenteils identisch sind, jedoch einige eindeutige Felder pro Typ haben?

Auf der Indexebene gibt es keinen Unterschied zwischen einem Typ, der mit wenigen Feldern verwendet wird, die spärlich verwendet werden, und zwischen mehreren Typen, die eine Reihe von nicht-spärlichen Feldern mit einigen nicht gemeinsam genutzten Feldern verwenden (dh der andere Typ verwendet das Feld niemals selbst) (s)).

Anders gesagt: Ein spärlich genutztes Feld ist unabhängig vom Typ im Index spärlich. Die Sparsity ist für den Index nicht von Vorteil oder schadet ihm nicht, nur weil er in einem separaten Typ definiert ist.

Sie sollten diese Typen nur kombinieren und ein separates Typenfeld hinzufügen.

• Warum müssen separate Typen Felder genau gleich definieren?

Denn jedes Feld wird auf Lucene-Ebene wirklich nur einmal definiert, unabhängig davon, wie viele Typen vorhanden sind. Die Tatsache, dass Typen überhaupt existieren, ist ein Merkmal von Elasticsearch und ist nur eine logische Trennung.

• Kann ich separate Typen definieren, bei denen das gleiche Feld anders definiert ist?

Wenn Sie in ES 2.x oder höher einen Weg finden, sollten Sie einen Fehlerbericht öffnen . Wie bereits in der vorigen Frage erwähnt, betrachtet Lucene sie alle als ein einziges Feld, so dass es keine Möglichkeit gibt, diese Arbeit angemessen zu gestalten.

ES 1.x beließ dies als eine implizite Anforderung, die es Benutzern ermöglichte, Bedingungen zu erstellen, bei denen die Zuordnungen eines Shards in einem Index tatsächlich von einem anderen Shard im selben Index abweichen. Dies war effektiv eine Wettlaufsituation und konnte zu unerwarteten Problemen führen.

Ausnahmen von der Regel

• Übergeordnete / untergeordnete Dokumente erfordern die Verwendung separater Typen innerhalb desselben Index.
  • Der Elternteil lebt in einem Typ.
  • Das Kind lebt in einem separaten Typ (aber jedes Kind lebt in demselben Shard wie sein Elternteil).
• Extrem Nischenanwendungen, bei denen die Erstellung von Tonnen von Indizes unerwünscht ist und die Auswirkung spärlicher Felder der Alternative vorzuziehen ist.
  • Das Elasticsearch Monitoring-Plugin Marvel (1.x und 2.x) oder X-Pack Monitoring (5.x +) überwacht Elasticsearch selbst auf Änderungen im Cluster, Knoten, Indizes, bestimmte Indizes (Indexebene), und sogar Scherben. Es könnten täglich mehr als 5 Indizes erstellt werden, um die Dokumente mit eindeutigen Zuordnungen zu isolieren, oder es kann gegen bewährte Methoden verstoßen, um die Clusterlast durch die gemeinsame Nutzung eines Index zu reduzieren (Hinweis: Die Anzahl der definierten Zuordnungen ist praktisch die gleiche, jedoch die Anzahl der erstellten Indizes wird von n auf 1) reduziert.
  • Dies ist ein erweitertes Szenario, aber Sie müssen die gemeinsam genutzten Felddefinitionen über Typen hinweg berücksichtigen!