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

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.

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

OM2: Un rendimiento de indexación hasta un 15% superior al de las instancias M7g OR1, un 66% más.

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

Datos de sensores y IoT: guarde los datos por segundo en almacenamiento activo de períodos recientes; acumule resúmenes por hora o por día para los datos más antiguos.

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.

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 y fuerce la fusión 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.

Plazos de compromiso de 1 o 3 años, sin opciones de pago por adelantado, parcial o totalmente anticipado.

Ideal para nodos de datos de nivel avanzado y nodos maestros dedicados que funcionan de forma continua.

Utilice la calculadora de AWS precios para estimar los ahorros antes de comprometerse.

Las instancias reservadas son un descuento de facturación que se aplica a las instancias bajo demanda, sin necesidad de realizar cambios en la infraestructura.

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

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.

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 (o OR2 las instancias eliminan OR1 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.

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.

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.

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.

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 el ajuste automático: 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.

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.

Admite los 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.

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

Integrado con las canalizaciones de ingestión de vectores.

Se puede combinar con la indexación acelerada por GPU para bases de datos vectoriales a escala multimillonaria.

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 solo con CPU.

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

GPUs se conectan de forma dinámica: solo se paga OCUs cuando la aceleración de la GPU está activa.

Permite crear bases de datos vectoriales a escala multimillonaria en menos de una hora.

Se carga por separado como aceleración vectorial. OCUs

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

Grupos de cobro: 1, 2, 4, 8, 16 y múltiplos de 16 a 1696. OCUs

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.

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

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

Filtre los campos en el momento de la ingesta: 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.

Anteriormente, cada clave KMS única requería una clave dedicada OCUs , 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 la OCU.

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

Soporta tanto el mínimo OCUs (línea base garantizada, sin arranques en frío) como el máximo OCUs (límite de costes).

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.