Tecniche di ottimizzazione dei costi per Amazon OpenSearch Service

OpenSearch memorizza ogni documento inserito due volte: una volta nel _source campo (documento non elaborato) e una volta come campi indicizzati per la ricerca.

Il _source campo da solo può occupare una notevole quantità di spazio di archiviazione, spesso il 30-50% dello spazio di archiviazione totale dell'indice.

Con Derived Source, si evita l'archiviazione _source e la si ricostruisce invece dinamicamente da campi indicizzati quando necessario (durante le operazioni di ricerca, get, mget, reindex o aggiornamento).

Si tratta di un opt-in, abilitato al momento della creazione dell'indice utilizzando le impostazioni dell'indice composito.

Disponibile in tutte le regioni in cui è supportata la versione OpenSearch 3.1 o successiva.

OR2: Throughput di indicizzazione fino al 26% superiore rispetto al 70% in più rispetto alle istanze R7g. OR1

OM2: Throughput di indicizzazione fino al 15% superiore rispetto alle istanze M7g, il 66% in più. OR1

Entrambe utilizzano la stessa architettura: EBS locale per lo storage principale e S3 per la durabilità.

Elimina i costi di storage delle repliche: repliche archiviate in S3 (durabilità 11 nove secondi) anziché in costosi volumi EBS.

Miglioramento del rapporto prezzo/prestazioni fino al 30% rispetto alle istanze della generazione precedente.

Supporta Shallow Snapshot v2, ossia istantanee quasi istantanee senza sovraccarico. I/O

Dati IoT/sensori: conserva i dati al secondo in hot storage per periodi recenti; aggrega i riepiloghi orari o giornalieri per i dati più vecchi.

Metriche di sistema: conserva le metriche dettagliate degli ultimi 30 giorni; aggrega i dati più vecchi in riepiloghi orari o giornalieri.

Dati di registro: conserva tutti i dettagli per la finestra di risoluzione dei problemi attiva (ad esempio, 1 settimana); mantieni i modelli di errore riepilogati per i periodi precedenti.

Combinalo con le politiche ISM per automatizzare il rollup e la migrazione a più livelli in un'unica politica del ciclo di vita.

Maggiori risparmi nell'aggregazione da secondi a ore rispetto a secondi a minuti.

Migrazione automatica degli indici: da Hot to Cold to Cold to Delete, in base UltraWarm all'età, alle dimensioni o al numero di documenti.

Attiva i rollup prima delle transizioni di livello per ridurre il volume di dati.

Imposta politiche di rollover (ad esempio, quando un indice raggiunge i 50 GB o ha 30 giorni) per controllare la crescita dell'indice.

Automatizza l'unione forzata sugli indici di sola lettura per recuperare spazio di archiviazione dai documenti eliminati.

Combinalo con i rollup per il massimo risparmio su set di dati di grandi serie temporali.

Termini di impegno di 1 o 3 anni senza opzioni di pagamento anticipato, anticipato parziale o completamente anticipato.

Ideale per nodi di dati di livello avanzato e nodi master dedicati che funzionano continuamente.

Usa il calcolatore AWS dei prezzi per stimare i risparmi prima di impegnarti.

Le istanze riservate sono uno sconto di fatturazione applicato alle istanze on demand: non sono necessarie modifiche all'infrastruttura.

Utilizza sempre istanze di ultima generazione (ad esempio, le istanze Graviton3 offrono prestazioni migliori fino al 25% rispetto alle istanze basate su Graviton2).

Utilizza i volumi EBS gp3 anziché gp2: prestazioni migliori a costi inferiori senza costi aggiuntivi.

Abbina il tipo di istanza al carico di lavoro: ottimizzata per la memoria per le ricerche intensive, ottimizzata per il calcolo per le attività di indicizzazione più impegnative.

Valuta i nodi dedicati alla gestione dei cluster: necessari solo per 3 o più nodi di dati; evita di sovradimensionare i nodi master con dimensioni eccessive.

Monitora i CloudWatch parametri per rilevare l'over-provisioning: CPU sostenuta inferiore al 40%, JVM inferiore al 50% e storage inferiore al 50% sono segnali di spreco.

Intervalli ottimali: CPU 60-80%, JVM 65-85%, storage 70-85% per carichi di lavoro sostenuti.

Dimensioni degli shard consigliate: 10-50 GiB per shard a seconda del carico di lavoro.

Non più di 25 shard per GiB di heap Java, non più di 1.000 shard per nodo di dati.

Utilizza le politiche di rollover di ISM per controllare la crescita degli indici ed evitare la proliferazione illimitata degli shard.

Riduci il numero di repliche laddove la durabilità lo consente (OR1/OR2 le istanze eliminano completamente la necessità di repliche).

Utilizza l'unione forzata sugli indici di sola lettura per ridurre il numero di segmenti e recuperare spazio di archiviazione.

Nessun costo di inserimento: i dati rimangono in S3.

Nessun costo di storage di livello superiore per i dati di archiviazione.

Pay-per-query modello di calcolo.

Supporta OpenSearch dashboard per la visualizzazione.

La latenza di secondi o minuti è accettabile, non per i casi d'uso in tempo reale.

Campionamento: inserisci solo un sottoinsieme rappresentativo di flussi di log ad alto volume (ad esempio, il 10% dei log di debug).

Compressione dell'indice: abilita il codec di compressione migliore per ridurre l'ingombro di archiviazione.

Filtraggio dei campi: elimina i campi ad alta cardinalità e con basso valore prima dell'indicizzazione (ad esempio, tracce di stack non elaborate per i vecchi log).

Politiche di conservazione: definisci finestre di conservazione massime in linea con i requisiti di conformità: non archiviare mai i dati a tempo indeterminato.

Il mantenimento di versioni precedenti e non supportate comporta costi aggiuntivi oltre ai costi delle istanze.

Esegui l'upgrade alle versioni attualmente supportate per evitare i costi di Extended Support.

Applica i tag di allocazione dei costi ai OpenSearch domini per un monitoraggio dettagliato dei costi per team o carico di lavoro.

Imposta CloudWatch allarmi per l'utilizzo dello storage, la pressione della JVM e la CPU per rilevare tempestivamente l'over-provisioning.

Usa AWS Cost Explorer per identificare i domini con un utilizzo costantemente basso.

Evaluate Auto-Tune: regola automaticamente le dimensioni dell'heap JVM e altre impostazioni per migliorare le prestazioni e ridurre lo spreco di risorse.

In modalità standard (in_memory), l'intero grafico HNSW viene caricato nella RAM, il che diventa proibitivamente costoso su larga scala.

In on_disk modalità, solo i vettori compressi (quantizzati) vengono conservati in memoria per la generazione candidata; i vettori a piena precisione vengono recuperati dal disco solo per la fase di rescoring finale (ricerca a due fasi).

Ciò riduce drasticamente il fabbisogno di RAM mantenendo al contempo un'elevata qualità di ricerca.

on_diskLa modalità predefinita utilizza una quantizzazione binaria 32x, riducendo i requisiti di memoria del 97% rispetto alla modalità in memoria.

Supporta i livelli di compressione: 2x (FP16), 4x (byte), 8x, 16x, 32x (binario).

Latenza P90 nell'intervallo 100-200 ms, adatta per carichi di lavoro che non richiedono tempi di risposta a una cifra di millisecondi.

Fornisce consigli di ottimizzazione in meno di un'ora.

Integrato con pipeline di ingestione vettoriale.

Può essere combinato con l'indicizzazione accelerata da GPU per database vettoriali su scala miliardaria.

Tempi di creazione degli indici da 6,4 a 13,8 volte più rapidi rispetto all'indicizzazione basata solo su CPU.

Costi OCU di indicizzazione inferiori fino al 75% per carichi di lavoro vettoriali con elevati livelli di scrittura.

GPUs sono collegati dinamicamente: paghi solo quando l'accelerazione GPU è attiva. OCUs

Consente di creare database vettoriali su scala miliardaria in meno di un'ora.

Caricato separatamente come accelerazione vettoriale. OCUs

Livello di account: qualsiasi valore fino a 1.700 OCUs (non limitato a multipli di 16).

Gruppi di raccolta: 1, 2, 4, 8, 16 e multipli di 16 fino a 1.696. OCUs

Imposta periodi di conservazione da 24 ore a 3.650 giorni per indice o modello di indice.

Amazon OpenSearch Service Serverless elimina automaticamente i dati nel miglior modo possibile (in genere entro 48 ore o il 10% del periodo di conservazione).

Le regole possono essere applicate a livello di raccolta, a livello di modello di indice o a livello di indice individuale: le regole più specifiche hanno la precedenza.

1 TiB/day ingestione con una conservazione di 30 giorni = circa 1 TiB di hot data = 20 OCUs per l'indicizzazione + 20 per la ricerca. OCUs

Riduzione a una conservazione di 7 giorni = circa 233 GiB di hot data = circa OCUs 4 per l'indicizzazione + 4 per la ricerca. OCUs

Filtra i campi al momento dell'inserimento: utilizza le pipeline per eliminare i campi di basso valore prima che raggiungano la raccolta.

Evita di importare dati duplicati o ridondanti: deduplica a livello di pipeline.

Usa le mappature degli indici appropriate: disabilita l'indicizzazione sui campi archiviati ma mai ricercati (). "index": false

Per le raccolte di ricerca: evitate di archiviare blob binari di grandi dimensioni o testo non elaborato che gonfia lo spazio di archiviazione senza valore di ricerca.

In precedenza, ogni chiave KMS unica richiedeva una chiave KMS dedicata, il che rendeva OCUs proibitivo l'isolamento per tenant.

Con i gruppi di raccolta, i tenant con chiavi di crittografia separate possono condividere la capacità dell'OCU.

Risparmi sui costi fino al 90% per un gran numero di carichi di lavoro degli inquilini più piccoli.

Supporta sia i valori minimi OCUs (base garantita, nessun avvio a freddo) che quelli massimi OCUs (limite di costo).

Le raccolte con diversi tipi di accesso alla rete (pubblico e VPC) possono coesistere nello stesso gruppo.

CloudWatch le metriche forniscono visibilità per gruppo sul consumo di risorse e sulla latenza.