Techniques d'optimisation des coûts pour Amazon OpenSearch Service

OpenSearch stocke chaque document ingéré deux fois : une fois dans le _source champ (document brut) et une fois sous forme de champs indexés pour la recherche.

Le _source champ à lui seul peut consommer un espace de stockage important, souvent de 30 à 50 % du stockage total de l'index.

Avec la source dérivée, vous ignorez le stockage _source et vous le reconstruisez dynamiquement à partir de champs indexés lorsque cela est nécessaire (pendant les opérations de recherche, de get, de mget, de réindexation ou de mise à jour).

Il s'agit d'une option optionnelle, activée lors de la création de l'index à l'aide des paramètres d'index composites.

Disponible dans toutes les régions où la OpenSearch version 3.1 ou ultérieure est prise en charge.

OR2: débit d'indexation jusqu'à 26 % supérieur à celui des instances R7g OR1, 70 % supérieur à celui des instances R7g.

OM2: débit d'indexation jusqu'à 15 % supérieur à celui des instances OR1 m7G, 66 % de plus.

Les deux utilisent la même architecture : EBS local pour le stockage principal et S3 pour la durabilité.

Élimine les coûts de stockage des répliques : les répliques sont stockées dans S3 (durabilité de 11 minutes) au lieu de volumes EBS onéreux.

Jusqu'à 30 % d'amélioration du rapport prix/performances par rapport aux instances de génération précédente.

Compatible avec Shallow Snapshot v2, c'est-à-dire des instantanés quasi instantanés, sans frais supplémentaires I/O .

Données relatives à l'IoT et aux capteurs : conservez les données par seconde dans un espace de stockage à chaud pour les périodes récentes ; convertissez-les en résumés horaires ou quotidiens pour les données plus anciennes.

Mesures du système : conservez les mesures détaillées des 30 derniers jours ; agrégez les anciennes données dans des résumés horaires ou quotidiens.

Données du journal : conservez tous les détails de la fenêtre de dépannage active (par exemple, 1 semaine) ; conservez les modèles d'erreur résumés pour les périodes plus anciennes.

Associez-le aux politiques ISM pour automatiser la migration cumulative et hiérarchisée dans le cadre d'une politique de cycle de vie unique.

Des économies plus importantes en agrégeant les secondes en heures plutôt que les secondes en minutes.

Migrez automatiquement les index : de chaud UltraWarm à froid pour supprimer, en fonction de l'âge, de la taille ou du nombre de documents.

Déclenchez des cumuls avant les transitions de niveaux afin de réduire le volume de données.

Définissez des politiques de report (par exemple, lorsqu'un index atteint 50 Go ou date de 30 jours) pour contrôler la croissance de l'indice.

Automatisez la fusion forcée sur les index en lecture seule pour récupérer de l'espace sur les documents supprimés.

Combinez avec des cumuls pour réaliser des économies maximales sur les grands ensembles de données de séries chronologiques.

Modalités d'engagement d'un an ou de 3 ans sans options de paiement initial, initial partiel ou initial complet.

Idéal pour les nœuds de données de niveau élevé et les nœuds maîtres dédiés qui s'exécutent en continu.

Utilisez le calculateur de AWS prix pour estimer les économies avant de vous engager.

Les instances réservées sont un discount de facturation appliqué aux instances à la demande. Aucune modification de l'infrastructure n'est nécessaire.

Utilisez toujours la dernière génération d'instances (par exemple, les instances Graviton3 offrent des performances jusqu'à 25 % supérieures à celles des instances basées sur Graviton2).

Utilisez des volumes EBS gp3 au lieu de gp2 pour de meilleures performances à moindre coût, sans frais supplémentaires.

Faites correspondre le type d'instance à la charge de travail : mémoire optimisée pour les recherches intensives, optimisation pour le calcul pour les fortes indexations.

Évaluez les nœuds de gestion de cluster dédiés : nécessaires uniquement pour 3 nœuds de données ou plus ; évitez de surdimensionner la taille des nœuds principaux.

Surveillez CloudWatch les indicateurs pour détecter le surprovisionnement : le maintien du processeur en dessous de 40 %, la JVM en dessous de 50 % et le stockage en dessous de 50 % sont des signes de gaspillage.

Plages optimales : processeur 60 à 80 %, JVM 65 à 85 %, stockage 70 à 85 % pour les charges de travail soutenues.

Tailles de partition recommandées : 10 à 50 GiB par partition en fonction de la charge de travail.

Pas plus de 25 partitions par GiB de mémoire Java, pas plus de 1 000 partitions par nœud de données.

Utilisez les politiques de roulement ISM pour contrôler la croissance de l'indice et éviter la prolifération illimitée des partitions.

Réduisez le nombre de répliques lorsque la durabilité le permet (OR1/les OR2 instances éliminent complètement le besoin de répliques).

Utilisez la fusion forcée sur les index en lecture seule pour réduire le nombre de segments et récupérer de l'espace de stockage.

Aucun coût d'ingestion : les données restent dans S3.

Aucun coût de stockage haut de gamme pour les données d'archivage.

Pay-per-query modèle de calcul.

Supporte les OpenSearch tableaux de bord pour la visualisation.

Une latence de quelques secondes ou minutes est acceptable, mais pas pour les cas d'utilisation en temps réel.

Échantillonnage : ingérez uniquement un sous-ensemble représentatif de flux de journaux à volume élevé (par exemple, 10 % des journaux de débogage).

Compression d'index : activez le meilleur codec de compression pour réduire l'encombrement du stockage.

Filtrage des champs : supprimez les champs à cardinalité élevée et à faible valeur avant l'indexation (par exemple, les traces de pile brutes pour les anciens journaux).

Politiques de conservation : définissez des fenêtres de conservation maximales conformes aux exigences de conformité. Ne stockez jamais les données indéfiniment.

Le fait de continuer à utiliser des versions plus anciennes et non prises en charge entraîne des frais supplémentaires en plus des coûts d'instance.

Effectuez une mise à niveau vers les versions actuellement prises en charge pour éviter les frais de support étendu.

Appliquez des balises de répartition des coûts aux OpenSearch domaines pour un suivi détaillé des coûts par équipe ou par charge de travail.

Définissez des CloudWatch alarmes relatives à l'utilisation du stockage, à la pression de la machine virtuelle Java et au processeur afin de détecter rapidement le surprovisionnement.

Utilisez AWS Cost Explorer pour identifier les domaines dont le taux d'utilisation est constamment faible.

Évaluez Auto-Tune : ajuste automatiquement la taille du segment de mémoire JVM et d'autres paramètres pour améliorer les performances et réduire le gaspillage de ressources.

En mode standard (in_memory), le graphe HNSW complet est chargé dans la RAM, ce qui devient prohibitif à grande échelle.

En on_disk mode, seuls les vecteurs compressés (quantifiés) sont conservés en mémoire pour la génération des candidats ; les vecteurs de précision maximale sont extraits du disque uniquement pour la phase de réévaluation finale (recherche en deux phases).

Cela réduit considérablement les besoins en RAM tout en maintenant une qualité de recherche élevée.

on_diskLe mode par défaut utilise une quantification binaire 32 fois, ce qui réduit les besoins en mémoire de 97 % par rapport au mode en mémoire.

Supporte les niveaux de compression : 2x (FP16), 4x (octet), 8x, 16x, 32x (binaire).

Latence P90 comprise entre 100 et 200 ms : adaptée aux charges de travail ne nécessitant pas de temps de réponse à un chiffre en millisecondes.

Fournit des recommandations d'optimisation en moins d'une heure.

Intégré aux pipelines d'ingestion de vecteurs.

Peut être combiné à une indexation accélérée par GPU pour des bases de données vectorielles à l'échelle d'un milliard.

Temps de création d'index 6,4 à 13,8 fois plus rapides par rapport à l'indexation basée uniquement sur le processeur.

Jusqu'à 75 % de réduction du coût de l'OCU d'indexation pour les charges de travail vectorielles intensives en écriture.

GPUs sont attachés dynamiquement : vous ne payez que OCUs lorsque l'accélération du GPU est active.

Permet de créer des bases de données vectorielles à l'échelle d'un milliard en moins d'une heure.

Chargé séparément sous forme d'accélération vectorielle OCUs.

Niveau du compte : toute valeur inférieure à 1 700 OCUs (non limitée aux multiples de 16).

Groupes de collecte : 1, 2, 4, 8, 16 et multiples de 16 jusqu'à 1 696 OCUs.

Définissez des périodes de rétention de 24 heures à 3 650 jours par index ou modèle d'index.

Amazon OpenSearch Service Serverless supprime automatiquement les données dans la mesure du possible (généralement dans les 48 heures ou 10 % de la période de conservation).

Les règles peuvent être appliquées au niveau de la collection, du modèle d'index ou au niveau de l'index individuel ; les règles plus spécifiques ont priorité.

1 TiB/day ingestion avec une rétention de 30 jours = environ 1 TiB de données chaudes = OCUs 20 pour l'indexation et 20 pour la recherche. OCUs

Réduction à 7 jours de rétention = environ 233 GiB de données chaudes = environ OCUs 4 pour l'indexation et 4 pour la recherche. OCUs

Filtrer les champs lors de l'ingestion : utilisez des pipelines pour supprimer les champs de faible valeur avant qu'ils n'atteignent la collection.

Évitez d'ingérer des données dupliquées ou redondantes : dédupliquez au niveau du pipeline.

Utilisez des mappages d'index appropriés : désactivez l'indexation sur les champs stockés mais jamais recherchés ()"index": false.

Pour les collections de recherche : évitez de stocker de gros blobs binaires ou du texte brut qui augmente l'espace de stockage sans valeur de recherche.

Auparavant, chaque clé KMS unique devait être dédiée, ce qui OCUs rendait l'isolation par locataire d'un coût prohibitif.

Avec les groupes de collecte, les locataires dotés de clés de chiffrement distinctes peuvent partager la capacité de l'OCU.

Des économies de coûts allant jusqu'à 90 % pour un grand nombre de petites charges de travail pour les locataires.

Supporte à la fois le minimum OCUs (base de référence garantie, pas de démarrages à froid) et le maximum OCUs (plafonnement des coûts).

Les collections avec différents types d'accès au réseau (public et VPC) peuvent coexister au sein d'un même groupe.

CloudWatch les métriques fournissent une visibilité par groupe sur la consommation de ressources et la latence.