Técnicas de optimización de costes para Amazon OpenSearch Service

Las siguientes son algunas de las técnicas más utilizadas para optimizar los costes al utilizar Amazon OpenSearch Service, tanto con clústeres gestionados como sin servidor. Como cada carga de trabajo es única, evalúe estas estrategias en función de sus patrones de uso específicos y valídelas en un entorno de prueba antes de aplicarlas a la producción.

Ahorre a lo grande con 1 año o Multi-Year con compromisos

Con Amazon OpenSearch Service, solo pagas por lo que utilizas sin coste mínimo ni requisitos de uso. Amazon OpenSearch Service ofrece dos modelos de implementación:

• En el caso de los clústeres gestionados, se le cobrarán, por ejemplo, las horas, el almacenamiento y la transferencia de datos. El precio depende del tipo de instancia y del nivel de almacenamiento que elija. Por ejemplo, puede utilizar los precios de Reserved Instance o ahorrar con Database Savings Plans en lugar de los precios bajo demanda.

• En el caso de Serverless, se le cobrará el cómputo y el almacenamiento por separado. La capacidad informática se mide en unidades OpenSearch informáticas (OCU), que corresponden a la CPU, la memoria y I/O los recursos necesarios para indexar datos o ejecutar consultas. La tecnología Serverless también está cubierta por Database Savings Plans.

Los Database Savings Plans son un modelo de precios flexible que reduce los costos de Amazon OpenSearch Service cuando te comprometes (medidos en $/hora) a una cantidad constante de uso durante un período de 1 año. Este plan de ahorro se aplica automáticamente al uso de instancias aprovisionadas y sin servidor que reúnan los requisitos, independientemente de la versión del motor, la familia de instancias, el tamaño, la opción de implementación o Región de AWS sin pago por adelantado. Para obtener más información, consulte la página de precios de Database Savings Plans.

Las instancias reservadas ofrecen un modelo de precios que reduce los costos de Amazon OpenSearch Service cuando se compromete con una configuración de instancia específica durante un período de 1 o 3 años. Las instancias reservadas ofrecen descuentos importantes en comparación con On-Demand los precios si reserva capacidad para un tipo, tamaño y tamaño de instancia en particular. Región de AWS Entre las opciones de pago se incluyen el pago por adelantado, el pago inicial parcial o el pago por adelantado, con descuentos mayores si se paga por adelantado. Para obtener más información, consulta la página de precios de las instancias reservadas de Amazon OpenSearch Service.

Optimización de costes para los clústeres gestionados por Amazon OpenSearch Service

Fuente derivada: omita el almacenamiento del campo _source

La fuente derivada es una función de optimización del almacenamiento que elimina la sobrecarga que supone almacenar el _source campo:

• OpenSearch almacena cada documento ingerido dos veces: una vez en el _source campo (documento sin procesar) y otra como campos indexados para la búsqueda.

• El _source campo por sí solo puede consumir un espacio de almacenamiento considerable, a menudo entre el 30 y el 50% del total del almacenamiento indexado.

• Con Derived Source, puede omitir el almacenamiento _source y, en su lugar, reconstruirlo dinámicamente a partir de campos indexados cuando es necesario (durante las operaciones de búsqueda, obtención, mget, reindexación o actualización).

• Esta opción es opcional y se habilita al crear el índice mediante una configuración de índice compuesto.

• Disponible en todas las regiones en las que se admite la OpenSearch versión 3.1 o posterior.

Ideal para: cargas de trabajo analíticas y de registro en las que no es necesario recuperar el documento original sin procesar con frecuencia, pero sí buscar y agregar campos.

Para obtener más información, consulte la documentación de código abierto y el anuncio sobre las novedades.

Instancias OR1/OR2/OM2: familias de instancias OpenSearch-optimized

OR1 y las instancias OR2 y OM2 más recientes utilizan Amazon S3 para el almacenamiento de réplicas mediante la replicación de segmentos:

• OR2: el rendimiento de indexación es hasta un 26% superior al de las instancias OR1, un 70% más que las instancias R7g.

• OM2: el rendimiento de indexación es hasta un 15% superior al de las instancias OR1 y un 66% más que las instancias M7g.

• Ambas utilizan la misma arquitectura: EBS local para el almacenamiento principal y S3 para mayor durabilidad.

• Elimina el costo del almacenamiento de réplicas: las réplicas se almacenan en S3 (con una durabilidad de 11 nueves) en lugar de los costosos volúmenes de EBS.

• Hasta un 30% de mejora en la relación precio-rendimiento con respecto a las instancias de la generación anterior.

• Admite la versión Shallow Snapshot v2, es decir, instantáneas casi instantáneas sin sobrecarga. I/O

Ideal para: cargas de trabajo de análisis Indexing-heavy operativo y análisis de registros.

Para obtener más información, consulte el anuncio sobre las novedades de OR2 y OM2 y el tema de la guía para OpenSearch Instancias optimizadas para dominios OpenSearch de Amazon Service desarrolladores.

Resumen de índices: agregue datos históricos de series temporales

Los resúmenes de índices resumen y comprimen los datos de series temporales más antiguas en intervalos de tiempo más gruesos, lo que reduce drásticamente el volumen de almacenamiento:

• IoT/sensor datos: guarde los datos por segundo de períodos recientes en un almacén activo; si los datos son más antiguos, acumule resúmenes diarios o por hora.

• Métricas del sistema: conserve las métricas detalladas de los últimos 30 días y agregue los datos más antiguos en resúmenes diarios o por hora.

• Datos de registro: conserve todos los detalles para el período de solución de problemas activo (por ejemplo, una semana); mantenga los patrones de error resumidos para los períodos anteriores.

• Combínelo con las políticas de ISM para automatizar la migración acumulativa y por niveles en una única política de ciclo de vida.

• Mayores ahorros al sumar segundos a horas en lugar de segundos a minutos.

Para obtener más información, consulta la entrada del blog Index Rollups.

Administración del estado de los índices: automatice todo el ciclo de vida de los datos

Las políticas de ISM automatizan el movimiento de los índices a través de los niveles de almacenamiento y las acciones del ciclo de vida:

• Migre automáticamente los índices: activos UltraWarm a fríos y eliminarlos, en función de la antigüedad, el tamaño o el número de documentos.

• Active las acumulaciones antes de la transición de nivel para reducir el volumen de datos.

• Establezca políticas de renovación (por ejemplo, cuando un índice alcance los 50 GB o tenga 30 días de antigüedad) para controlar el crecimiento del índice.

• Automatice la fusión forzada en índices de solo lectura para recuperar el espacio de almacenamiento de los documentos eliminados.

• Combínelo con paquetes acumulativos para ahorrar al máximo en conjuntos de datos de series temporales de gran tamaño.

Right-size tipos y recuento de instancias

La guía clave de The Well-Architected OpenSearch Lens y las mejores prácticas para dimensionar correctamente:

• Utilice siempre instancias de la última generación (por ejemplo, las instancias Graviton3 ofrecen un rendimiento hasta un 25% superior al de las instancias). Graviton2-based

• Utilice los volúmenes EBS de gp3 en lugar de los de gp2: mejor rendimiento a un coste menor sin coste adicional.

• Haga coincidir el tipo de instancia con la carga de trabajo: optimizada en memoria para búsquedas intensivas, optimizada para procesamiento en caso de alta indexación.

• Evalúe los nodos de administrador de clústeres dedicados: solo se necesitan para 3 o más nodos de datos; evite aprovisionar en exceso el tamaño del nodo maestro.

• Supervise CloudWatch las métricas para detectar el sobreaprovisionamiento: mantener la CPU por debajo del 40%, la JVM por debajo del 50% y el almacenamiento por debajo del 50% son señales de despilfarro.

• Rangos óptimos: entre un 60 y un 80% de CPU, entre un 65 y un 85% de JVM y entre un 70 y un 85% de almacenamiento para cargas de trabajo sostenidas.

Para obtener más información, consulte la entrada del blog sobre prácticas Right-Sizing recomendadas.

Optimización de fragmentos: evite la fragmentación excesiva

Over-sharding es un factor de coste oculto: demasiados fragmentos pequeños desperdician CPU, memoria y pila de JVM:

• Tamaños de partición recomendados: de 10 a 50 GiB por fragmento, según la carga de trabajo.

• No más de 25 fragmentos por GiB de pila de Java, no más de 1000 fragmentos por nodo de datos.

• Utilice las políticas de transferencia de ISM para controlar el crecimiento del índice y evitar la proliferación ilimitada de fragmentos.

• Reduzca el número de réplicas cuando la durabilidad lo permita (OR1/OR2 las instancias eliminan por completo la necesidad de réplicas).

• Utilice la combinación forzada en índices de solo lectura para reducir el número de segmentos y recuperar espacio de almacenamiento.

Para obtener más información, consulte ¿Cuántos fragmentos necesito?

Zero-ETL /Consulta directa con Amazon S3

Para los datos que rara vez se consultan pero que deben permanecer accesibles, Direct Query (cero ETL con S3) permite consultar datos de S3 directamente desde OpenSearch allí sin ingerirlos:

• Sin coste de ingesta: los datos permanecen en S3.

• El archivado de los datos no supone un coste excesivo de almacenamiento.

• Pay-per-query modelo de cómputo.

• Admite OpenSearch paneles de control para la visualización.

• La latencia de segundos o minutos es aceptable, no en casos de uso en tiempo real.

Toma de muestras y compresión en el momento de la ingestión

Reduzca los costes incluso antes de que los datos lleguen a OpenSearch:

• Muestreo: ingiera solo un subconjunto representativo de flujos de registros de gran volumen (por ejemplo, el 10% de los registros de depuración).

• Compresión de índices: habilite el mejor códec de compresión para reducir el espacio de almacenamiento.

• Filtrado de campos: elimine los campos de alta cardinalidad y bajo valor antes de indexarlos (por ejemplo, los rastreos de pila sin procesar de registros antiguos).

• Políticas de retención: defina los intervalos de retención máximos en función de los requisitos de conformidad; nunca almacene los datos de forma indefinida.

Evite los costos de soporte prolongados: manténgase al día con las versiones del motor

Amazon OpenSearch Service cobra una tarifa fija por hora de instancia normalizada para las versiones de motor de Extended Support:

• El uso de versiones antiguas y no compatibles conlleva cargos adicionales además de los costes de la instancia.

• Actualice a las versiones compatibles actuales para evitar las tarifas de Extended Support.

Asignación de costos, etiquetas y CloudWatch monitoreo

La gobernanza proactiva de los costes evita el derroche:

• Aplica etiquetas de asignación de costes a OpenSearch los dominios para realizar un seguimiento detallado de los costes por equipo o carga de trabajo.

• Establezca CloudWatch alarmas para la utilización del almacenamiento, la presión de la JVM y la CPU para detectar el sobreaprovisionamiento de forma temprana.

• Utilice AWS Cost Explorer para identificar los dominios con una utilización baja y constante.

• Evalúe Auto-Tune : ajusta automáticamente el tamaño del montón de la JVM y otros ajustes para mejorar el rendimiento y reducir el desperdicio de recursos.

Optimización de costes para Amazon OpenSearch Service Serverless

Disk-optimized búsqueda vectorial (colecciones vectoriales)

Disk-optimized La búsqueda vectorial es una de las técnicas de reducción de costes más eficaces para las cargas de trabajo vectoriales. Ejecuta la búsqueda vectorial a una fracción del coste del modo en memoria, ya que solo mantiene los vectores comprimidos en la RAM y almacena los vectores de máxima precisión en el disco.

Funcionamiento:

• En el modo standard (in_memory), el gráfico HNSW completo se carga en la RAM, lo que resulta prohibitivo a gran escala.

• En on_disk el modo, solo los vectores comprimidos (cuantificados) se guardan en la memoria para la generación de los candidatos; los vectores de máxima precisión se recuperan del disco únicamente para la fase final de repuntuación (búsqueda bifásica).

• Esto reduce drásticamente los requisitos de RAM y, al mismo tiempo, mantiene una alta calidad de búsqueda.

• El on_disk modo predeterminado utiliza una cuantificación binaria de 32 veces, lo que reduce los requisitos de memoria en un 97% en comparación con el modo en memoria.

• Soporta niveles de compresión: 2x (FP16), 4x (byte), 8x, 16x, 32x (binario).

• Latencia P90 en el rango de 100 a 200 ms: adecuada para cargas de trabajo que no requieren tiempos de respuesta de milisegundos de un solo dígito.

Parámetros de ahorro de costes:

Conjunto de datos	Recordemos @100	Latencia del P90	Reducción de costos
Cohesión TREC-RAG	0.94	104 ms	83%
Tasb-1M	0,96	7 ms	67%
Marco-1M	0.99	7 ms	67%

Ideal para: canalizaciones de RAG, búsqueda semántica, recuperación de documentos y cualquier carga de trabajo vectorial en la que una latencia de P90 de 100 a 200 ms sea aceptable y la reducción de costes sea una prioridad.

nota

Para aplicar este cambio a los datos indexados existentes, debe volver a indexarlos. Puede utilizar una herramienta de canalización externa, por ejemplo, para volver a indexar los datos en un índice nuevo.

Para obtener más información, consulte la entrada del blog Disk-Optimized Vector Search, la entrada del blog Quantization Techniques y. Trabajo con colecciones de búsqueda vectorial

Vector Auto-Optimize (colecciones de vectores)

Auto-optimize evalúa automáticamente las configuraciones de los índices vectoriales y recomienda el mejor equilibrio entre la calidad de búsqueda, la latencia y el coste de la memoria, sin necesidad de conocimientos sobre vectores:

• Ofrece recomendaciones de optimización en menos de una hora.

• Integrado con las canalizaciones de ingestión de vectores.

• Se puede combinar con la GPU-accelerated indexación para bases de datos vectoriales a escala multimillonaria.

Para obtener más información, consulta la entrada del Auto-Optimize blog.

GPU-accelerated indexación vectorial (colecciones vectoriales)

La aceleración por GPU descarga la indexación vectorial HNSW a las GPU sin servidor, lo que reduce drásticamente el tiempo y el coste de OCU que supone crear índices vectoriales de gran tamaño:

• Los tiempos de creación de índices son entre 6,4 y 13,8 veces más rápidos en comparación con la indexación. CPU-only

• Hasta un 75% menos de coste de indexación de la OCU para cargas de trabajo vectoriales de escritura intensa.

• Las GPU se conectan de forma dinámica: solo pagas por las OCU cuando la aceleración de la GPU está activa.

• Permite crear bases de datos vectoriales a escala de miles de millones en menos de una hora.

• Se cargan por separado como OCU de aceleración vectorial.

Ideal para: ingestión Large-scale inicial de vectores o escenarios frecuentes de reentrenamiento de modelos en los que la reconstrucción de los índices resulta costosa.

Para obtener más información, consulta la entrada del blog GPU Acceleration.

Establece los límites máximos de OCU (todos los tipos de colecciones)

Amazon OpenSearch Service Serverless escala automáticamente las OCU en función de la demanda. Sin un límite, los costos pueden aumentar inesperadamente. Establezca un límite máximo de OCU a nivel de cuenta o por grupo de cobranza para evitar una expansión descontrolada. El sistema se amplía hasta este límite durante los picos de carga, pero no lo superará.

Valores permitidos:

• Nivel de cuenta: cualquier valor de hasta 1700 OCU (no limitado a múltiplos de 16).

• Grupos de recopilación (NextGen): 0, 2, 4, 8, 16 y múltiplos de 16 a 1696 OCU.

• Grupos de recopilación (clásicos): 1, 2, 4, 8, 16 y múltiplos de 16 a 1696 OCU.

Supervisa CloudWatch las métricas (OCUUtilization) para ajustar tu configuración máxima de OCU a lo largo del tiempo.

nota

Si la utilización alcanza el límite máximo de OCU, el rendimiento puede degradarse considerablemente aunque los costes estén contenidos. Alcanzar el límite no resuelve la causa subyacente del aumento de la OCU. En el caso de las colecciones de vectores, la causa principal suelen ser los vectores en memoria, que deben abordarse directamente optimizando la indexación vectorial, reduciendo el tamaño del índice o ajustando las compensaciones entre la recuperación y la precisión.

sugerencia

Comience con una OCU máxima conservadora y aumente solo cuando CloudWatch muestre una utilización sostenida cerca del límite. Si siempre llegas al límite, investiga la causa principal (especialmente el uso de vectores en memoria para las colecciones de vectores) en lugar de limitarte a aumentar el límite.

Para obtener más información, consulte Administración de los límites de capacidad de Amazon OpenSearch Serverless.

Optimice el período de retención (recopilaciones de series temporales)

Las políticas del ciclo de vida de los datos eliminan automáticamente los datos de las recopilaciones de series temporales después de un período de retención específico, lo que evita un crecimiento ilimitado del almacenamiento. Solo las recopilaciones de series temporales respaldan las políticas del ciclo de vida de los datos; las recopilaciones vectoriales y de búsqueda no.

El recuento de OCU para las recopilaciones de series temporales depende directamente de la cantidad de datos recientes que deben guardarse en el almacenamiento local. Time-series Las recopilaciones guardan solo la parte más reciente de los datos en el almacenamiento local de la OCU; los datos más antiguos se transfieren a S3 y el número de OCU se escala en consecuencia:

OCU necesarios = máximo (OCU mínimos, OCU necesarios para almacenar los datos dentro del período de retención)

Configuración de políticas del ciclo de vida de los datos:

• Establezca períodos de retención de 24 horas a 3650 días por índice o patrón de índice.

• Amazon OpenSearch Service Serverless elimina los datos automáticamente haciendo el mejor esfuerzo posible (normalmente en un plazo de 48 horas o el 10% del período de retención).

• Las reglas se pueden aplicar a nivel de recopilación, a nivel de patrón de índice o a nivel de índice individual; prevalecen las reglas más específicas.

Ejemplo de dimensionamiento:

• 1 TiB/day ingesta con una retención de 30 días = aproximadamente 1 TiB de datos calientes = 20 OCU para indexación + 20 OCU para búsqueda.

• Reducir a una retención de 7 días = aproximadamente 233 GiB de datos importantes = aproximadamente 4 OCU para indexación + 4 OCU para búsqueda.

Una retención más corta significa menos datos importantes en el almacenamiento local, se necesitan menos OCU y una factura informática más baja. Alinee los períodos de retención con los requisitos empresariales y de cumplimiento reales; de forma predeterminada, no conserve los datos indefinidamente.

Para obtener más información, consulte Uso de políticas del ciclo de vida de los datos con Amazon OpenSearch Serverless.

Evite almacenar datos innecesarios (todos los tipos de recopilación)

Al reducir el volumen de datos ingeridos, se reducen directamente los costes de cómputo (OCUs) y de almacenamiento:

• Filtre los campos al ingerirlos: utilice canalizaciones para eliminar los campos de bajo valor antes de que lleguen a la colección.

• Evite ingerir datos duplicados o redundantes: deduplique a nivel de canalización.

• Utilice las asignaciones de índice adecuadas: desactive la indexación en los campos que están almacenados pero que nunca se buscan (). "index": false

• Para las colecciones de búsquedas: evite almacenar bloques binarios grandes o texto sin procesar, ya que aumenta el espacio de almacenamiento sin valor de búsqueda.

Grupos de recopilación para cargas de trabajo con varios usuarios (todos los tipos de recopilación)

Los grupos de recopilación permiten que varias recopilaciones con diferentes claves de KMS compartan los recursos de la OCU dentro del mismo límite de seguridad, lo que reduce drásticamente los costos de las arquitecturas multiusuario. Aplicable a los clientes que utilizan varias claves KMS por inquilino o por colección:

• Anteriormente, cada clave KMS única requería OCU dedicadas, lo que hacía que el aislamiento por inquilino fuera prohibitivo.

• Con los grupos de recopilación, los inquilinos con claves de cifrado independientes pueden compartir la capacidad de las OCU.

• Ahorro de costes de hasta un 90% para un gran número de cargas de trabajo para inquilinos más pequeños.

• Admite OCU mínimos (línea base garantizada, sin arranques en frío) y OCU máximos (límite de coste).

• Las colecciones con diferentes tipos de acceso a la red (pública y VPC) pueden coexistir en el mismo grupo.

• CloudWatch las métricas proporcionan visibilidad por grupo sobre el consumo de recursos y la latencia.

Ideal para: proveedores de SaaS, plataformas multiusuario o cualquier carga de trabajo con muchas colecciones pequeñas, cada una de las cuales requiera su propia clave de KMS.

Para obtener más información, consulte la entrada del blog sobre los grupos de colecciones, el anuncio sobre las novedades y. Grupos de recopilación de Amazon OpenSearch Serverless