Techniken zur Kostenoptimierung für Amazon OpenSearch Service

OpenSearch speichert jedes aufgenommene Dokument zweimal: einmal im _source Feld (Rohdokument) und einmal als indizierte Felder für die Suche.

Das _source Feld allein kann viel Speicherplatz beanspruchen — oft 30-50% des gesamten Indexspeichers.

Mit Derived Source überspringen Sie das Speichern _source und rekonstruieren es stattdessen bei Bedarf dynamisch aus indizierten Feldern (bei Such-, Get-, Mget-, Reindex- oder Aktualisierungsvorgängen).

Dies ist Opt-In, das bei der Indexerstellung mithilfe der Einstellungen für den zusammengesetzten Index aktiviert wird.

In allen Regionen verfügbar, in denen OpenSearch 3.1 oder höher unterstützt wird.

OR2: Bis zu 26% höherer Indizierungsdurchsatz als bei R7g-Instances OR1, 70% mehr.

OM2: Bis zu 15% höherer Indizierungsdurchsatz als bei OR1 M7g-Instances, 66% mehr.

Beide verwenden dieselbe Architektur: lokales EBS für den Primärspeicher und S3 für Stabilität.

Eliminiert die Kosten für Replikatspeicher — Replikate werden in S3 (Haltbarkeit von 11 bis 9 Minuten) statt in teuren EBS-Volumes gespeichert.

Bis zu 30% besseres Preis-Leistungs-Verhältnis im Vergleich zu Instances der vorherigen Generation.

Unterstützt Shallow Snapshot v2 — quasi sofortige Snapshots ohne Mehraufwand. I/O

IoT-/Sensordaten: Bewahren Sie Daten pro Sekunde für die letzten Zeiträume im Hot-Storage auf; führen Sie stündliche oder tägliche Zusammenfassungen für ältere Daten zusammen.

Systemmetriken: Behalten Sie detaillierte Kennzahlen der letzten 30 Tage bei; fassen Sie ältere Daten in stündlichen oder täglichen Zusammenfassungen zusammen.

Protokolldaten: Behalten Sie alle Details für das aktive Fehlerbehebungsfenster bei (z. B. 1 Woche); behalten Sie die zusammengefassten Fehlermuster für ältere Zeiträume bei.

Kombinieren Sie es mit ISM-Richtlinien, um Rollup und Tier-Migration in einer einzigen Lebenszyklus-Richtlinie zu automatisieren.

Größere Einsparungen bei der Aggregation von Sekunden zu Stunden im Vergleich zu Sekunden zu Minuten.

Automatische Migration von Indizes: Hot to Cold UltraWarm to Delete, basierend auf Alter, Größe oder Anzahl der Dokumente.

Um das Datenvolumen zu reduzieren, lösen Sie Rollups vor Tierwechseln aus.

Legen Sie Rollover-Richtlinien fest (z. B. wenn ein Index 50 GB erreicht oder 30 Tage alt ist), um das Indexwachstum zu kontrollieren.

Automatisieren Sie die erzwungene Zusammenführung schreibgeschützter Indizes, um Speicherplatz aus gelöschten Dokumenten zurückzugewinnen.

Kombinieren Sie es mit Rollups, um maximale Einsparungen bei großen Zeitreihendatensätzen zu erzielen.

Laufzeit von 1 oder 3 Jahren mit den Zahlungsoptionen „Keine Vorauszahlung“, „Teilweise Vorauszahlung“ oder „Vollständige Vorauszahlung“.

Am besten für Hot-Tier-Datenknoten und dedizierte Master-Knoten, die kontinuierlich laufen.

Verwenden Sie den AWS Preisrechner, um die Einsparungen abzuschätzen, bevor Sie sich verpflichten.

Reserved Instances sind ein Abrechnungsrabatt, der für On-Demand-Instances gewährt wird — es sind keine Änderungen an der Infrastruktur erforderlich.

Verwenden Sie immer die neueste Generation von Instances (Graviton3-Instances bieten beispielsweise eine um bis zu 25% bessere Leistung als Graviton2-basierte Instances).

Verwenden Sie gp3-EBS-Volumes anstelle von gp2-Volumes — bessere Leistung bei geringeren Kosten ohne zusätzliche Kosten.

Passen Sie den Instance-Typ an die Arbeitslast an: speicheroptimiert für suchintensive Anwendungen, rechenoptimiert für indexintensive Anwendungen.

Evaluieren Sie dedizierte Cluster-Manager-Knoten: Wird nur für 3 oder mehr Datenknoten benötigt; vermeiden Sie eine zu große Anzahl an Master-Knoten.

Überwachen Sie die CloudWatch Messwerte, um zu viel Provisioning zu erkennen: Dauerhafte CPU-Werte unter 40%, JVM unter 50% und Speicherplatz unter 50% sind Anzeichen für Verschwendung.

Optimale Bereiche: CPU 60— 80%, JVM 65— 85%, Speicher 70— 85% für dauerhafte Workloads.

Empfohlene Shard-Größen: 10—50 GiB pro Shard, je nach Arbeitslast.

Nicht mehr als 25 Shards pro GiB Java-Heap, nicht mehr als 1.000 Shards pro Datenknoten.

Verwenden Sie ISM-Rollover-Richtlinien, um das Indexwachstum zu kontrollieren und eine uneingeschränkte Verbreitung von Shards zu verhindern.

Reduzieren Sie die Anzahl der Replikate, wo es die Haltbarkeit zulässt (OR1OR2 /-Instances machen Replikate vollständig überflüssig).

Verwenden Sie Force Merge für schreibgeschützte Indizes, um die Anzahl der Segmente zu reduzieren und Speicherplatz zurückzugewinnen.

Keine Aufnahmekosten — Daten bleiben in S3.

Keine Hot-Tier-Speicherkosten für Archivdaten.

Pay-per-query Modell berechnen.

Unterstützt OpenSearch Dashboards zur Visualisierung.

Eine Latenz von Sekunden oder Minuten ist akzeptabel — nicht für Echtzeit-Anwendungsfälle.

Probenahme: Erfassen Sie nur einen repräsentativen Teil der Protokollstreams mit hohem Volumen (z. B. 10% der Debug-Logs).

Indexkomprimierung: Aktivieren Sie den Codec mit der besten Komprimierung, um den Speicherbedarf zu reduzieren.

Feldfilterung: Löschen Sie Felder mit hoher Kardinalität und niedrigem Wert vor der Indizierung (z. B. rohe Stack-Traces für alte Logs).

Aufbewahrungsrichtlinien: Definieren Sie maximale Aufbewahrungsfenster entsprechend den Compliance-Anforderungen — speichern Sie Daten niemals unbegrenzt.

Wenn Sie bei älteren, nicht unterstützten Versionen bleiben, fallen zusätzlich zu den Instance-Kosten zusätzliche Gebühren an.

Führen Sie ein Upgrade auf die aktuell unterstützten Versionen durch, um Gebühren für erweiterten Support zu vermeiden.

Wenden Sie Tags zur Kostenzuweisung auf OpenSearch Domänen an, um eine detaillierte Kostenverfolgung pro Team oder Arbeitslast zu ermöglichen.

Richten Sie CloudWatch Alarme für Speicherauslastung, JVM-Druck und CPU ein, um Überprovisionierung frühzeitig zu catch.

Verwenden Sie den AWS Cost Explorer, um Domänen mit durchweg geringer Auslastung zu identifizieren.

Evaluate Auto-Tune — passt automatisch die JVM-Heap-Größe und andere Einstellungen an, um die Leistung zu verbessern und Ressourcenverschwendung zu reduzieren.

Im Standardmodus (in_memory) wird der vollständige HNSW-Graph in den Arbeitsspeicher geladen — was im großen Maßstab unerschwinglich teuer wird.

Im on_disk Modus werden nur komprimierte (quantisierte) Vektoren für die Kandidatengenerierung im Speicher aufbewahrt. Vektoren mit voller Genauigkeit werden nur für die letzte Rescoring-Phase (zweiphasige Suche) von der Festplatte abgerufen.

Dadurch werden die RAM-Anforderungen drastisch reduziert und gleichzeitig die hohe Suchqualität beibehalten.

Der on_disk Standardmodus verwendet eine 32-fache binäre Quantisierung, wodurch der Speicherbedarf im Vergleich zum In-Memory-Modus um 97% reduziert wird.

Unterstützt die folgenden Komprimierungsstufen: 2x (FP16), 4x (Byte), 8x, 16x, 32x (binär).

P90-Latenz im Bereich von 100 bis 200 ms — geeignet für Workloads, die keine Reaktionszeiten im einstelligen Millisekundenbereich erfordern.

Liefert Optimierungsempfehlungen in weniger als einer Stunde.

Integriert in Vektor-Ingestion-Pipelines.

Kann mit GPU-beschleunigter Indexierung für Vektordatenbanken im Milliardenbereich kombiniert werden.

6,4- bis 13,8-mal schnellere Indexerstellungszeiten im Vergleich zur reinen CPU-Indizierung.

Bis zu 75% niedrigere OCU-Kosten für die Indizierung bei schreibintensiven Vektor-Workloads.

GPUs werden dynamisch angeschlossen — Sie zahlen nur, OCUs wenn die GPU-Beschleunigung aktiv ist.

Ermöglicht die Erstellung milliardenschwerer Vektordatenbanken in weniger als einer Stunde.

Wird separat als Vector Acceleration berechnet. OCUs

Kontoebene: Jeder Wert bis zu 1.700 OCUs (nicht auf ein Vielfaches von 16 beschränkt).

Sammelgruppen: 1, 2, 4, 8, 16 und Vielfache von 16 bis zu 1.696. OCUs

Legen Sie Aufbewahrungszeiträume von 24 Stunden bis 3.650 Tagen pro Index oder Indexmuster fest.

Amazon OpenSearch Service Serverless löscht Daten automatisch nach bestem Wissen und Gewissen (in der Regel innerhalb von 48 Stunden oder 10% der Aufbewahrungsfrist).

Regeln können auf Sammlungsebene, Indexmusterebene oder Ebene einzelner Indizes angewendet werden — spezifischere Regeln haben Vorrang.

1 TiB/day Aufnahme mit einer Aufbewahrung von 30 Tagen = ungefähr 1 TiB an heißen Daten = 20 OCUs für die Indizierung + 20 für die Suche. OCUs

Reduzierung auf eine Aufbewahrung von 7 Tagen = ungefähr 233 GiB an heißen Daten = ungefähr 4 OCUs für die Indizierung + 4 OCUs für die Suche.

Felder bei der Erfassung filtern: Verwenden Sie Pipelines, um Felder mit geringem Wert zu löschen, bevor sie die Sammlung erreichen.

Vermeiden Sie die Aufnahme doppelter oder redundanter Daten: Deduplizieren Sie auf Pipeline-Ebene.

Verwenden Sie geeignete Indexzuordnungen: Deaktivieren Sie die Indizierung von Feldern, die gespeichert, aber nie durchsucht wurden (). "index": false

Für Suchsammlungen: Vermeiden Sie es, große binäre Blobs oder Rohtext zu speichern, der den Speicherplatz ohne Suchwert in die Höhe treibt.

Bisher war für jeden einzelnen KMS-Schlüssel ein eigener Schlüssel erforderlich, sodass OCUs die Isolierung pro Mandant unerschwinglich teuer war.

Bei Sammelgruppen können Mandanten mit separaten Verschlüsselungsschlüsseln die OCU-Kapazität gemeinsam nutzen.

Kosteneinsparungen von bis zu 90% bei einer großen Anzahl kleinerer Mandanten-Workloads.

Unterstützt sowohl den Mindestwert OCUs (garantierter Basiswert, keine Kaltstarts) als auch den Höchstwert OCUs (Kostenobergrenze).

Sammlungen mit unterschiedlichen Netzwerkzugriffstypen (öffentlich und VPC) können in derselben Gruppe koexistieren.

CloudWatch Metriken bieten gruppenspezifische Einblicke in den Ressourcenverbrauch und die Latenz.