Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Elasticsearch Grundkurs

Den Speicher optimieren

Testen Sie unsere 2016 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Die Belegung des Arbeitsspeichers sollte sinnvoll geplant sein, denn die Suchgeschwindigkeit hängt wesentlich von den verschiedenen Caches und der Größe des Arbeitsspeichers ab. Machen Sie sich daher in diesem Film mit den Möglichkeiten vertraut, um den für Elasticsearch verfügbaren Speicher zu optimieren.

Transkript

Die Akzeptanz einer Datenbank steht und fällt mit der Geschwindigkeit mit der sie auf Anfragen antwortet. ElasticSearch bildet hier keine Ausnahme. Um Ihre ElasticSearch-Instanz optimal für die Anforderungen der Nutzer gestalten zu können, zeige ich Ihnen in diesem Video das Rüstwerkzeug, wie Sie Arbeitsspeicher, als auch Datenspeicher so konfigurieren, um auf einer einzigen Instanz die optimale Geschwindigkeit herausholen zu können. Beginnen wir also zunächst einmal mit der Konfiguration der Java Virtual Machine, die von ElasticSearch genutzt wird. Die wohl wichtigste Einstellung ist die Größe des Arbeitsspeichers, der Ihrer ElasticSearch-Instanz zur Verfügung steht. Allem voran gibt es hier zwei wichtige Optionen, "Xms" und "Xmx". Beide stehen für die Menge an Arbeitsspeicher, die die Java Virtual Machine reserviert, in diesem Fall 2 GB. Optimalerweise insofern der Server lediglich eine ElasticSearch-Instanz beinhaltet, ist hier etwa die Größe des Arbeitsspeichers durch "2" angegeben, also bei 10 Gb Arbeitsspeicher beispielsweise 5 GB. "Xmx" stellt hierbei die obere Grenze dar. "Xmx" stellt die Menge an Arbeitsspeicher dar, die initial reserviert wird, sobald ElasticSearch gestartet wird. Dieser Wert sollte gerade bei einer Datenbank genauso groß sein, wie der maximale Speicher, Sodass ElasticSearch von Hause aus auf den gesamten Arbeitsspeicher, der zur Verfügung steht, zugreifen kann. Der Grund, dass man hier lediglich die Hälfte des zur Verfügung stehenden Arbeitsspeichers verwendet, ist, dass eine Datenbank, wie ElasticSearch auch zum Großteil mit dem Dateisystem zusammenarbeitet, und das darunter liegende Betriebssystem, ob Linux oder Windows, verwaltet zusätzlich Arbeitsspeicher, der die Zugriffszeiten auf die jeweiligen Datenbankdateien verkürzt. das bedeutet, sollte man ElasticSearch den gesamten Arbeitsspeicher zur Verfügung stellen, so kann das Betriebssystem nicht mehr optimal garantieren, dass auf Daten im Speicher schnell zugegriffen werden kann. Alternativ können Sie vor dem Starten von ElasticSearch den Parameter "ES_JAVA_OPTS" auf den jeweilig gewünschten Arbeitsspeicher-Wert stellen.... Ist das soweit geschehen, können Sie nun Ihre ElasticSearch-Instanz starten. Neben den Einstellungen für die Java Virtual Machine gibt es noch Einstellungen, die ElasticSearch selbst verwaltet. dazu gehören vor allem die Größe von Caches, als auch Speicherbuffern, allem voran der Index-Buffer. beim Speichern von Datensätzen der ElasticSearch, werden diese nicht unmittelbar in die Datendateien geschrieben, also auf die Festplatte, sondern eine gewisse Menge, je nach Größe des Arbeitsspeichers, wird noch im Arbeitsspeicher vorgehalten, und erst dann persistiert, sobald neue Daten dazukommen oder die Instanz beendet wird. In diesem Fall ist nun der Wert auf 10 % gestellt. das bedeutet, 10% des Arbeitsspeichers von ElasticSearch werden dafür verwendet, dass Daten zunächst einmal nicht direkt auf die Festplatte geschrieben werden. Der Grund dafür ist relativ einfach. Sollte ElasticSearch immer sofort auf die Festplatte schreiben, werden die Speichergeschwindigkeiten deutlich geringer und weniger Datensätze könnten in einem kurzen Zeitraum geschrieben werden. Außerdem gibt es noch den sogenannten Query-Cache, hier eingestellt mit einer Größe von 20 % des ElasticSearch zugewiesenen Arbeitsspeichers. Für den Query-Cache hat ElasticSearch einen besonderen Algorithmus. Für abfragen, die besonders oft stattfinden, als auch eine größere Menge an Zeit zur Beantwortung brauchen, nutzt die ElasticSearch automatisch den eigenen Query-Cache, sodass eine Frage nicht immer unmittelbar aus dem Index beantwortet wird, sondern mit bereits berechneten Ergebnissen. Dieser Cache wird immer dann invalidiert, sobald Änderungen in diesem Index stattfinden, damit eine neue Berechnung auch die aktuell korrekten Ergebnisse liefert. Ein Wert von 20 % ist genügend. Der Fielddata-Chache ist standardmäßig unbegrenzt in ElasticSearch. Dieser wird genutzt, um einen Index von der Festplatte, aus einer Chart-Datei in den Arbeitsspeicher von ElasticSearch zu laden, um eine Suchanfrage beispielsweise beantworten zu können, damit stellt er also für die Beantwortung von Suchanfragen den wohl wichtigsten Chache dar. Ist der Fielddata-Cache nicht groß genug, können anfragen auf große Indizes nicht beantwortet werden. sollten Sie also keinen bestimmten Grund haben, hier einen Wert festzulegen, können sie diese Option auch ignorieren. Neben dem Query-Cache gibt es noch den Requests-Cache, denn beim Beantworten einer Suchanfrage tragen im Regelfall mehrere Charts zum Ergebnis bei, und ein solcher Chart in einem Index kann beispielsweise beim erneuten Ausführen eines Querys so seine Daten wieder liefern, ohne Daten von der Festplatte laden zu müssen. Normalerweise lässt man diesen Cache auf sehr kleinen Werten. Alternativ zu den Prozentwerten kann auch für jede dieser Größen ein absoluter Speicherwert angegeben werden, wie beispielsweise 512 MB. Eine weitere wichtige Option sind die Orte, an denen die Datendateien gespeichert werden. Hier definiert mit "path.data". An dieser Stelle kann man mehr als nur einen einzigen Pfad getrennt durch Komas eingeben. Damit werden für den jeweiligen Server die Datendateien über diese beiden Orte verteilt. Das führt lediglich dazu, dass Datendateien von separaten Speicherorten geladen werden und so die Festplatten-Zugriffszeiten geringer werden können. Dabei handelt es sich nicht um ein Redundanz-Konzept. Diese sollte über die regulären Backup und Repliziermechanismen von ElasticSearch abgebildet werden. Zu guter Letzt gibt es noch eine sehr interessante Option, die ich hier über die API konfiguriere. Alle Einstellungen, die man so eben gesehen hat, können auch über die API und die Möglichkeiten von "unverständlich" Cluster und Settings konfiguriert werden. in einer ähnlichen Struktur kann man hier persistente Konfigurationen festlegen, als auch temporäre Konfigurationen. Sollte man also eine temporäre Konfiguration wünschen, lassen sich diese Konfigurationsbeschreibungen einfach unter "transient" eintragen. Diese gelten dann also nur, solang die aktuelle ElasticSearch-Instanz in Ihrem Cluster gestartet ist. Neben den absoluten Chache-Größen gibt es noch sogenannte Secret Breaker, in dem Fall definiert durch die Option "indices breaker. Dabei handelt es sich um Größen, die verhindern, dass bestimmte Suchanfragen Schwellwerte überschreiten bei der Benutzung des Arbeitsspeichers. So kann innerhalb des Total-Limit eine Speichergrenze festgelegt werden, die nicht überschritten werden darf bei der Beantwortung einer Anfrage, sollte also eine Anfrage mehr als 60% des Arbeitsspeichers nutzen wollen. Ähnliches gilt hier für die Daten, die aus dem Index geladen werden. Bei der Beantwortung einer Suchanfrage versucht die ElasticSearch auch von Host aus die benötigte Speichermenge einzuschätzen. Werden auch dabei schon die Werte überschritten, so wird eine Suchanfrage gar nicht erst ausgeführt. Sie sollten nun also verstanden haben, dass ausschlaggebend für die Menge an Arbeitsspeicher, die ElasticSearch nutzt, die Java Options sind, konkret "Xms" und "Xmx". Idealerweise werden diese Werte also auf 50% des der Maschine zur Verfügung stehenden Arbeitsspeichers gestellt, der Rest ist für Optimierung des Betriebssystem vorgesehen. Außerdem haben Sie den Index-Buffer-Cache kennengelernt. Dieser Dient dem Abfedern von Schreiboperationen, um höhere Persistenzgeschwindigketen garantieren zu können. Des Weiteren habe Sie den Fielddata-Cache kennengelernt, der bei der Beantwortung von Suchanfragen dafür sorgt, dass ein Index in den Arbeitsspeicher geladen wird. Der Query-Cache versucht häufige Suchanfragen mit längeren Beantwortungszeiten aus dem Cache heraus zu bearbeiten. Der Requests-Cache dient lokal Mechanismen in Charts, um frequente Suchen schnell beantworten zu können. Für den Datenspeicher haben Sie den Mechanismus kennengelernt, bei dem Sie multiple Orte für das Speichern der Datendateien festlegen können. sie sollte dabei auf jeden Fall beachten, dass dies kein Mechanismus zum Garantieren für Redundanz ist, sondern lediglich dazu führt, dass die Verteilung von Datendateien bessere Festplattenzugriffszeiten nutzen kann.

Elasticsearch Grundkurs

Lernen Sie, Elasticsearch und seine Einsatzgebiete zu verstehen und mit der API zu interagieren.

2 Std. 19 min (23 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Themen:
Programmierung
Exklusiv für Abo-Kunden
Erscheinungsdatum:23.02.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!