Ich versuche zu verstehen, was ein Shard und Replika in Elasticsearch ist, aber ich habe es nicht geschafft zu verstehen. Wenn ich Elasticsearch herunterlade und das Skript ausführe, dann habe ich meines Wissens nach einen Cluster mit einem einzelnen Knoten gestartet. Jetzt hat dieser Knoten (mein PC) 5 Shards (?) und einige Replikate (?).
Was sind sie, habe ich 5 Duplikate des Index? Wenn ja, warum? Ich könnte eine Erklärung gebrauchen.
In einfachsten Begriffen ist der Shard nichts anderes als ein Teil eines Index, der auf der Festplatte in einem separaten Ordner gespeichert ist:
In diesem Screenshot ist das gesamte Elasticsearch-Verzeichnis zu sehen.
Wie Sie sehen können, werden alle Daten in das data-Verzeichnis geschrieben.
Bei der Inspektion des Index C-mAfLltQzuas72iMiIXNw sehen wir, dass er fünf Shards (Ordner 0 bis 4) hat.
Andererseits hat der Index JH_A8PgCRj-GK0GeQ0limw nur einen Shard (Ordner 0).
Der pri zeigt die Gesamtzahl der Shards an.
Ich werde dies anhand von realen Szenarien erklären. Stellen Sie sich vor, Sie betreiben eine E-Commerce-Website. Je populärer Sie werden, desto mehr Verkäufer und Produkte fügen Sie Ihrer Website hinzu. Sie werden feststellen, dass die Anzahl der Produkte, die indiziert werden müssen, gewachsen ist und zu groß ist, um auf eine Festplatte eines einzelnen Knotens zu passen. Selbst wenn es auf die Festplatte passt, ist eine lineare Suche durch alle Dokumente auf einer Maschine extrem langsam. Ein Index auf einem Knoten nutzt nicht die verteilte Clusterkonfiguration, auf der Elasticsearch funktioniert.
Deswegen teilt Elasticsearch die Dokumente im Index auf mehrere Knoten im Cluster auf. Jede Aufteilung des Dokuments wird als Shard bezeichnet. Jeder Knoten, der einen Shard eines Dokuments trägt, hat nur einen Teil des Dokuments. Nehmen wir an, Sie haben 100 Produkte und 5 Shards, jeder Shard wird 20 Produkte enthalten. Diese Aufteilung der Daten ist es, was schnelle Suchvorgänge mit geringer Latenz in Elasticsearch möglich macht. Die Suche wird parallel auf mehreren Knoten durchgeführt. Die Ergebnisse werden zusammengeführt und zurückgegeben. Allerdings bieten die Shards keine Ausfallsicherung. Das bedeutet, dass wenn ein Knoten, der den Shard enthält, nicht verfügbar ist, wird der Clusterstatus gelb. Das bedeutet, dass einige Daten nicht verfügbar sind.
Um die Ausfallsicherheit zu erhöhen, kommen Replikate ins Spiel. Standardmäßig erstellt Elastic Search eine einzige Replik jedes Shards. Diese Replikate werden immer auf einem anderen Knoten erstellt, auf dem sich der primäre Shard nicht befindet. Daher müssen Sie möglicherweise die Anzahl der Knoten in Ihrem Cluster erhöhen, um das System ausfallsicher zu machen, dies hängt auch von der Anzahl der Shards Ihres Index ab. Die allgemeine Formel zur Berechnung der Anzahl der benötigten Knoten basierend auf Replikaten und Shards lautet "Anzahl der Knoten = Anzahl der Shards * (Anzahl der Replikate + 1)". Die Standardpraxis ist, mindestens ein Replikat für die Ausfallsicherheit zu haben.
Das Festlegen der Anzahl der Shards ist ein statischer Vorgang, das bedeutet, dass Sie es angeben müssen, wenn Sie einen Index erstellen. Jede Änderung danach erfordert eine komplette Neuindizierung der Daten und wird Zeit in Anspruch nehmen. Das Festlegen der Anzahl der Replikate ist jedoch ein dynamischer Vorgang und kann jederzeit nach der Indexerstellung durchgeführt werden.
Sie können die Anzahl der Shards und Replikate für Ihren Index mit dem folgenden Befehl einrichten.
curl -XPUT 'localhost:9200/sampleindex?pretty' -H 'Content-Type: application/json' -d '
{
"settings":{
"number_of_shards":2,
"number_of_replicas":1
}
}'
Nicht eine Antwort, sondern eine weitere Referenz für Kernkonzepte zu ElasticSearch, und ich denke, sie sind ziemlich klar als Ergänzung zur Antwort von @javanna.
Ein Index kann potenziell eine große Menge an Daten speichern, die die Hardwaregrenzen eines einzelnen Knotens überschreiten können. Zum Beispiel kann ein einzelner Index von einer Milliarde Dokumenten, der 1 TB Speicherplatz einnimmt, nicht auf die Festplatte eines einzelnen Knotens passen oder zu langsam sein, um Suchanfragen alleine von einem einzelnen Knoten aus zu bedienen.
Um dieses Problem zu lösen, bietet Elasticsearch die Möglichkeit, Ihren Index in mehrere Teile namens Shards zu unterteilen. Wenn Sie einen Index erstellen, können Sie einfach die Anzahl der Shards definieren, die Sie möchten. Jeder Shard ist selbst ein voll funktionsfähiger und unabhängiger "Index", der auf jedem Knoten im Cluster gehostet werden kann.
Sharding ist aus zwei Hauptgründen wichtig:
- Es ermöglicht Ihnen, Ihr Inhaltsvolumen horizontal zu aufzuteilen/skalieren.
- Es ermöglicht es Ihnen, Operationen über Shards zu verteilen und parallelisieren (potenziell auf mehreren Knoten), um die Leistung/Durchsatz zu erhöhen.
In einer Netzwerk-/Cloud-Umgebung, in der Ausfälle jederzeit erwartet werden können, ist es sehr nützlich und sehr empfehlenswert, einen Ausfallsicherungsmechanismus zu haben, falls ein Shard/Knoten aus irgendeinem Grund offline geht oder verschwindet. Zu diesem Zweck ermöglicht es Elasticsearch, eine oder mehrere Kopien Ihrer Index-Shards in sogenannte Replikations-Shards oder kurz Replikate zu erstellen.
Replikation ist aus zwei Hauptgründen wichtig:
- Sie bietet hohe Verfügbarkeit, falls ein Shard/Knoten ausfällt. Aus diesem Grund ist es wichtig zu beachten, dass ein Replikations-Shard niemals auf demselben Knoten zugewiesen wird wie der originale/primäre Shard, von dem er kopiert wurde.
- Es ermöglicht es Ihnen, Ihr Suchvolumen/Durchsatz zu erweitern, da Suchen auf allen Replikaten parallel ausgeführt werden können.
Elasticsearch ist dank seiner verteilten Architektur hervorragend skalierbar. Dies wird durch Sharding ermöglicht. Bevor wir weiter darauf eingehen, wollen wir einen einfachen und sehr häufigen Anwendungsfall betrachten. Nehmen wir an, Sie haben einen Index, der eine Vielzahl von Dokumenten enthält, und der Einfachheit halber nehmen wir an, dass die Größe dieses Indexes 1 TB beträgt (d. h. Summe der Größen eines jeden Dokuments in diesem Index beträgt 1 TB). Angenommen, Sie haben auch zwei Knoten, von denen jeder 512 GB Speicherplatz für die Datenspeicherung zur Verfügung hat. Wie deutlich zu erkennen ist, kann unser gesamter Index nicht in einem der beiden verfügbaren Knoten gespeichert werden, und daher müssen wir unseren Index auf diese Knoten verteilen.
In Fällen, in denen die Größe eines Indexes die Hardwaregrenzen eines einzelnen Knotens übersteigt, kommt Sharding zur Rettung. Sharding löst dieses Problem, indem es die Indizes in kleinere Teile aufteilt und diese Teile als Shards bezeichnet werden.
In ElasticSearch werden Dokumente auf oberster Ebene in Indizes indexiert. Jeder Index hat eine bestimmte Anzahl von Shards, die die Daten intern verteilen, und innerhalb der Shards befinden sich die Lucene-Segmente, die den Kernspeicher der Daten darstellen. Wenn der Index also 5 Shards hat, bedeutet dies, dass die Daten über die Shards verteilt wurden und nicht dieselben Daten in den Shards vorhanden sind.
Schauen Sie sich das Video an, das den Kern von ES erklärt https://www.youtube.com/watch?v=PpX7J-G2PEo
Artikel über mehrere Indizes oder mehrere Shards Elastic search, multiple indexes vs one index and types for different data sets?
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
