Amazon OpenSearch Service introduce il writable warm storage, un tier caldo su cui si può scrivere direttamente. Fino a oggi UltraWarm era la scelta economica per i dati storici, ma read-only: per aggiornare anche un solo documento bisognava migrare l’indice di nuovo su hot, scrivere e rimigrare indietro. Il post è firmato AWS, quindi le cifre vanno lette con l’occhio di chi vende; detto questo, il meccanismo tecnico è chiaro.
Il collo di bottiglia di UltraWarm è quel round trip: force merge, snapshot e shard relocation che consumano CPU, memoria e disco sui nodi hot. AWS quantifica circa 130 minuti per un indice da 100 GB, misurati su un dominio con 3 nodi hot r6g.2xlarge, 3 nodi ultrawarm1.large e 3 leader dedicati, con indice a shard singolo e una replica; i tempi reali variano.
Come funziona
I nodi writable warm usano le istanze OpenSearch Optimized (OI2), la stessa famiglia dei nodi hot con storage durevole su Amazon S3. Dato che i dati sono già persistiti su S3, il passaggio di tier diventa una shard relocation leggera invece di una migrazione pesante. Il motore Lucene lavora identico sui due tier, quindi il warm accetta scritture, background merge e refresh periodici come l’hot. Servono OpenSearch Service 3.3 o successivo, istanze OI2 e un refresh interval minimo di 5 secondi. Il cold tier non è supportato.
Costi e prestazioni
La novità sui costi è che OI2 permette il Reserved Instance pricing, assente su UltraWarm: con impegno a 1 o 3 anni AWS indica un risparmio del 31-52 percento rispetto ai nodi UltraWarm, mentre il nuovo Database savings plan porta circa il 22 percento. Nel confronto proposto — 2 TB al giorno, 210 giorni di retention — la possibilità di scrivere sul warm fa scendere la retention hot da 30 a 7 giorni, con un totale mensile che va da 74.427 a 69.297 dollari on-demand, fino a un -48 percento con RI a 3 anni. Sul benchmark NYC Taxis, il writable warm eguaglia o batte UltraWarm su 6 dei 7 tipi di query a P90.
La lettura per un data engineer: se avete dati storici immutabili a breve retention, UltraWarm on-demand può restare più economico. Il writable warm conviene quando servono scritture occasionali sui dati vecchi (backfill, correzioni di compliance, dati in ritardo) o quando potete impegnarvi su RI ed eliminare le pipeline di migrazione.
In sintesi
- Tier warm scrivibile su OI2 e S3: niente più round trip warm-hot-warm per aggiornare dati storici.
- Reserved Instance sul warm per la prima volta, fino a -48% a 3 anni nel confronto AWS; richiede OpenSearch 3.3 e OI2.
- Per dati immutabili a breve retention UltraWarm resta valido; il cold tier non è coperto.
Fonte: Cut costs and simplify operations with writable warm storage in Amazon OpenSearch Service
Hai qualcosa da aggiungere? Unisciti alla discussione.