Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pilier d'efficacité des performances

Le pilier de l'efficacité des performances du AWS Well-Architected Framework se concentre sur la manière d'optimiser les performances lors de l'ingestion ou de l'interrogation de données. L'optimisation des performances est un processus progressif et continu comprenant les éléments suivants :

Le pilier relatif à l'efficacité des performances fournit des directives qui peuvent vous aider à choisir un modèle de données performant. Le pilier de l'efficacité des performances inclut les meilleures pratiques d'optimisation des requêtes et des écritures.

Le pilier de l'efficacité en matière de performance se concentre sur les domaines clés suivants :

Modélisation des données d'afflux et optimisation des requêtes

La conception d'un schéma efficace est cruciale pour optimiser les performances et les capacités de requête des données de séries chronologiques dans InfluxDB. Commencez par choisir les bons tags et les bons champs. InfluxDB indexe les balises, de sorte que le moteur de requête n'a pas besoin de scanner chaque enregistrement d'une mesure pour localiser la valeur d'une balise. Cela signifie que l'interrogation des balises est plus efficace que l'interrogation des champs. Pour compacter et stocker les données, le moteur de stockage regroupe les valeurs de champ par clé de série, puis classe ces valeurs de champ par heure. Une clé de série est définie par une mesure, une clé et une valeur de balise, et une clé de champ. Pour plus d'informations sur la conception des données, consultez la documentation InfluxDB.

Le moteur de stockage utilise un format de données TSM (Time-Structured Merge Tree). Pour plus d'informations sur le format de données TSM, consultez la documentation InfluxDB.

Imaginez que vous collectez des données (timestamp,host_id,region,cpu,,memory, network_in_bytesnetwork_out_bytes,disk_io) dans le cadre d'un cas d' DevOps utilisation. Les balises, y compris l'horodatage de l'enregistrement, fournissent un contexte qui permet d'identifier qui, quoi, quand et où se trouve un enregistrement. Les balises sont utilisées pour organiser et classer les données, ainsi que pour filtrer les données dans le cadre d'une requête.

Les region balises host_id et sont idéales pour organiser et classer les cas DevOps d'utilisation. Ces colonnes permettent de filtrer les données pour un hôte particulier ou d'exécuter une analyse en fonction de la colonne de région.

Les mesures fournissent la base pour effectuer des calculs mathématiques (tels que le calcul des totaux, des moyennes et des différences de taux de variation) et une analyse quantitative de vos données. Par conséquent,cpu,memory, network_in_bytesnetwork_out_bytes, et disk_io capturez les indicateurs importants liés à ceux DevOps qui évoluent au fil du temps. Vous pouvez utiliser ces métriques pour effectuer diverses analyses, telles que le calcul du processeur et de la mémoire sur différents hôtes. Vous pouvez utiliser ces valeurs métriques pour prendre des décisions basées sur les données afin d'éviter les interruptions de production et de planifier l'infrastructure.

La cardinalité est la combinaison de valeurs de balises uniques. Essayez de maintenir la cardinalité aussi faible que possible. Si votre application nécessite un identifiant unique pour chaque point de données, utilisez des valeurs de champ plutôt que des valeurs de balise. Cela se traduira par une latence des requêtes nettement meilleure. Une bonne conception du schéma peut empêcher une cardinalité élevée des séries, ce qui améliore les performances des requêtes. Si vous remarquez un ralentissement de la lecture et de l'écriture des données ou si vous souhaitez savoir comment la cardinalité affecte les performances, consultez la documentation Timestream for InfluxDB.

Si votre application émet des objets JSON, convertissez-les en colonnes individuelles (balises ou champs) et chargez les colonnes dans InfluxDB. InfluxDB est conçu pour les données de séries chronologiques. L'organisation de vos données avec des colonnes individuelles est donc une bonne pratique pour tirer pleinement parti des fonctionnalités du service.

Une seule instance OSS InfluxDB v2.7 prend en charge environ 20 compartiments InfluxDB écrits ou interrogés activement dans toutes les organisations. Plus de 20 compartiments peuvent avoir une incidence négative sur les performances. Certaines options de configuration d'InfluxDB sont limitées, et vous pouvez configurer certaines options en fonction de votre cas d'utilisation. Validez la configuration en fonction de la charge de travail de l'application pendant la phase de test. Les rétentions de données étant configurées au niveau du compartiment, les données présentant des exigences de conservation différentes doivent être stockées dans différents compartiments. Pour plus d'informations sur les options de configuration, consultez la documentation Timestream for InfluxDB.

Stockez les données dans des valeurs de balise ou des valeurs de champ, et non dans des clés de balise, des clés de champ ou des mesures. Si vous concevez votre schéma pour stocker les données sous forme de balises et de valeurs de champs, vos requêtes seront plus faciles à écrire et plus efficaces. Pour en savoir plus sur les meilleures pratiques en matière de modélisation des données, consultez la section Conception axée sur les performances.

Utilisez les tâches InfluxDB pour pré-agréger les données, charger les données dans différentes mesures ou compartiments, et générer des données pour les tableaux de bord et les visualisations à partir de celles-ci.

InfluxDB OSS expose un /metrics point de terminaison qui renvoie des métriques de performances, de ressources et d'utilisation formatées au format d'exposition en texte brut Prometheus. Utilisez les modèles InfluxDB pour configurer la surveillance et les alertes afin de détecter de manière proactive les problèmes, tels que la latence élevée des requêtes, la dégradation du débit d'écriture ou les pics d'utilisation des ressources.

Timestream for InfluxDB fournit un stockage inclus dans Influx IO. La sélection de la taille d'IOPS appropriée peut accélérer considérablement l'exécution des requêtes. Cela est particulièrement utile pour les requêtes qui doivent analyser de grandes quantités de données ou traiter un large éventail de demandes. Dans certains cas, il peut être nécessaire de combiner le dimensionnement de l'instance et l'amélioration des IOPS pour obtenir les améliorations de performances souhaitées.

Nous recommandons de faire correspondre les environnements de développement et de production (classe d'instance, type de stockage, configurations). Testez les modifications dans l'environnement inférieur pour chaque version avant de passer à la production. Sur les volumes de stockage inclus dans Influx IO, Timestream for InfluxDB fournit trois niveaux de stockage préconfigurés avec des IOPS optimaux (3 000, 12 000, 16 000) et un débit requis pour différents types de charges de travail. La plupart des cas d'utilisation nécessitent moins de 3 000 IOPS. Choisissez 12 000 ou 16 000 uniquement si les tests de performances indiquent un besoin d'IOPS élevées. Pour plus d'informations, consultez la section Configuration de la documentation Timestream for InfluxDB.

Optimisez les écritures

Pour optimiser les écritures dans InfluxDB, nous recommandons d'écrire les données par lots de 5 000 lignes de protocole de ligne par requête afin de minimiser la surcharge réseau. Pour de meilleures performances, triez les balises par clé dans l'ordre lexicographique avant d'écrire des points de données. L'utilisation de la précision temporelle la plus grossière possible pour les horodatages, au lieu des nanosecondes, peut également améliorer les performances. L'activation de la compression gzip est un autre moyen d'accélérer les écritures et de réduire la bande passante du réseau. Dans la configuration du plugin de influxdb_v2 sortie de votre telegraf.conf fichier, définissez l'content_encodingoption surgzip. La mise en œuvre de ces optimisations peut améliorer de manière significative les performances et l'efficacité de l'écriture de données dans InfluxDB. Pour plus d'informations sur les meilleures pratiques d'écriture d'InfluxDB, voir Optimiser les écritures dans InfluxDB.

Les performances d'écriture d'InfluxDB sont souvent étroitement liées aux IOPS disponibles. Lors de l'écriture de données, InfluxDB doit effectuer un nombre important d'opérations d'E/S pour stocker les données. Lorsque vous augmentez les IOPS, InfluxDB peut traiter plus d'écritures par seconde.