Berechnung der Speicheranforderungen - OpenSearch Amazon-Dienst

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Berechnung der Speicheranforderungen

Die meisten OpenSearch Workloads lassen sich in eine von zwei großen Kategorien einteilen:

  • Langlebiger Index: Sie schreiben Code, der Daten in einem oder mehreren Indizes verarbeitet und diese OpenSearch Indizes dann regelmäßig aktualisiert, wenn sich die Quelldaten ändern. Einige allgemeine Beispiele sind Suchen auf Websites, in Dokumenten und für e-Commerce-Zwecke.

  • Rolling-Indizes: Daten fließen kontinuierlich in einen Satz temporärer Indizes mit einem Indizierungszeitraum und einem Aufbewahrungsfenster (z. B. einen Satz täglicher Indizes, der zwei Wochen lang aufbewahrt wird). Einige allgemeine Beispiele sind Protokollanalyse, Zeitreihenverarbeitung und Clickstream-Analyse.

Für langlebige Index-Workloads können Sie die Quelldaten auf dem Datenträger untersuchen und einfach bestimmen, wie viel Speicherplatz dafür benötigt wird. Wenn die Daten aus mehreren Quellen stammen, addieren Sie diese Quellen einfach.

Für Rolling-Indizes können Sie die während eines repräsentativen Zeitraums generierten Datenmenge mit dem Aufbewahrungszeitraum multiplizieren. Wenn Sie beispielsweise 200 MiB Protokolldaten pro Stunde generieren, sind das 4,7 GiB pro Tag, also 66 GiB Daten zu jedem Zeitpunkt, wenn Sie einen Aufbewahrungszeitraum von zwei Wochen verwenden.

Die Größe Ihrer Datenquelle ist jedoch nur ein Aspekt Ihrer Speicheranforderungen. Außerdem müssen Sie Folgendes berücksichtigen:

  • Anzahl der Replikate: Jedes Replikat ist eine vollständige Kopie des primären Shards. Die Speichergröße des Indexes gibt die Größe an, die der Primär- und der Replikat-Shard einnehmen. Standardmäßig hat jeder OpenSearch Index ein Replikat. Wir empfehlen, mindestens eines zu verwenden, um sich gegen Datenverlust zu schützen. Replikate können auch die Suchleistung verbessern. Wenn Sie einen hohen Workload haben, können Sie in Betracht ziehen, mehrere zu erstellen. Verwenden Sie PUT /my-index/_settings, um die number_of_replicas-Einstellung für Ihren Index zu aktualisieren.

  • OpenSearch Indizierungsaufwand: Die Größe eines Indexes auf der Festplatte variiert. Die Gesamtgröße der Quelldaten plus Index beträgt oft 110 % der Quelle, wobei der Index bis zu 10 % der Quelldaten ausmacht. Nachdem Sie Ihre Daten indiziert haben, können Sie die _cat/indices?v-API und den pri.store.size-Wert verwenden, um den genauen Zusatzaufwand zu berechnen. _cat/allocation?v bietet auch eine nützliche Zusammenfassung.

  • Für das Betriebssystem reservierter Speicherplatz: Standardmäßig reserviert Linux 5 % des Dateisystems für den root-Benutzer für kritische Prozesse, zur Systemwiederherstellung und zum Schutz vor Problemen mit der Festplattenfragmentierung.

  • OpenSearch Serviceaufwand: Der OpenSearch Service reserviert 20% des Speicherplatzes jeder Instanz (bis zu 20 GiB) für Segmentzusammenführungen, Protokolle und andere interne Operationen.

    Aufgrund dieses Höchstwerts von 20 GiB kann die Gesamtmenge an reserviertem Speicherplatz stark variieren und hängt von der Anzahl der Instances in Ihrer Domain ab. Beispiel: Eine Domain kann drei m6g.xlarge.search-Instances haben, mit jeweils 500 GiB Speicherplatz, also insgesamt 1,46 TiB. In diesem Fall beträgt der gesamte reservierte Speicherplatz nur 60 GiB. Eine andere Domain kann 10 m3.medium.search-Instances haben, mit jeweils 100 GiB Speicherplatz, also insgesamt 0,98 TiB. Hier beträgt der gesamte reservierte Speicherplatz 200 GiB, auch wenn die erste Domain 50 % größer ist.

    In der folgenden Formel wenden wir eine „Worst-Case“-Schätzung für den Zusatzaufwand an. Diese Schätzung beinhaltet zusätzlichen freien Speicherplatz, um die Auswirkungen von Knotenausfällen und Ausfällen der Availability Zone zu minimieren.

Wenn Sie insgesamt jederzeit 66 GiB Quelldaten haben und ein Replikat verwenden wollen, liegt Ihr minimaler Speicherbedarf nahe 66 * 2 * 1,1/0,95/0,8 = 191 GiB. Sie können diese Berechnung wie folgt verallgemeinern:

Quelldaten * (1 + Anzahl von Replikaten) * (1 + Indexierungsaufwand)/(1 — reservierter Linux-Speicherplatz)/(1 — OpenSearch Serviceaufwand) = Mindestspeicherbedarf

Sie können diese vereinfachte Version verwenden:

Quelldaten * (1 + Anzahl der Replikate) * 1,45 = Mindestspeicheranforderung

Unzureichender Speicherplatz ist eine der häufigsten Ursachen für Clusterinstabilität. Sie sollten also die Zahlen überprüfen, wenn Sie Instance-Typen, Instance-Anzahlen und Speicher-Volumes auswählen.

Es gibt weitere Überlegungen zum Speicher.