

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Pilastro dell'efficienza delle prestazioni
<a name="performance-efficiency"></a>

Il [pilastro dell'efficienza delle prestazioni del AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/performance-efficiency.html) Framework si concentra su come ottimizzare le prestazioni durante l'acquisizione o l'interrogazione dei dati. L'ottimizzazione delle prestazioni è un processo incrementale e continuo che prevede quanto segue:
+ Conferma dei requisiti aziendali
+ Misurazione delle prestazioni del carico di lavoro
+ Identificazione dei componenti poco performanti
+ Ottimizzazione dei componenti per soddisfare le esigenze aziendali

Il pilastro relativo all'efficienza delle prestazioni fornisce linee guida che possono aiutarti a scegliere un modello di dati ad alte prestazioni. Il pilastro relativo all'efficienza delle prestazioni include le migliori pratiche di ottimizzazione delle query e della scrittura.

Il pilastro dell'efficienza delle prestazioni si concentra sulle seguenti aree chiave:
+ Modellazione dei dati di afflusso e ottimizzazione delle query
+ Ottimizzazione della scrittura

## Modellazione dei dati di afflusso e ottimizzazione delle query
<a name="data-modeling"></a>

La progettazione di uno schema efficace è fondamentale per ottimizzare le prestazioni e le capacità di interrogazione dei dati di serie temporali in InfluxDB. Inizia scegliendo i tag e i campi giusti. InfluxDB indicizza i tag, quindi il motore di query non deve scansionare ogni record di una misurazione per individuare il valore di un tag. Ciò significa che l'interrogazione dei tag è più efficiente dell'interrogazione dei campi. Per compattare e archiviare i dati, il motore di archiviazione raggruppa i valori dei campi per chiave di serie, quindi ordina tali valori di campo in base all'ora. Una chiave di serie è definita dalla misurazione, dalla chiave e dal valore del tag e dalla chiave di campo. Per ulteriori informazioni sulla progettazione dei dati, consulta la documentazione di [InfluxDB.](https://docs.influxdata.com/influxdb/v2/reference/key-concepts/data-elements/)

Il motore di archiviazione utilizza un formato di dati Time-Structured Merge Tree (TSM). [Per ulteriori informazioni sul formato di dati TSM, consulta la documentazione di InfluxDB.](https://docs.influxdata.com/influxdb/v2/reference/internals/storage-engine/#time-structured-merge-tree-tsm)

Immagina di raccogliere dati (`timestamp`,,,`host_id`,`region`, `cpu` `memory` `network_in_bytes``network_out_bytes`,`disk_io`) come parte di un DevOps caso d'uso. I tag, incluso il timestamp del record, forniscono un contesto che aiuta a identificare chi, cosa, quando e dove di un record. I tag vengono utilizzati per organizzare e classificare i dati e per filtrare i dati come parte di una query.

I `region` tag `host_id` and sono i tag ideali per organizzare e classificare il caso DevOps d'uso. Queste colonne aiutano a filtrare i dati per un determinato host o a eseguire analisi in base alla colonna della regione.

Le misure forniscono la base per eseguire calcoli matematici (come il calcolo di totali, medie e differenze nel tasso di variazione) e analisi quantitative sui dati. Pertanto,,`cpu`, `memory` `network_in_bytes``network_out_bytes`, e `disk_io` acquisisci metriche importanti relative a DevOps ciò che cambia nel tempo. È possibile utilizzare queste metriche per eseguire varie analisi, ad esempio il calcolo della CPU e della memoria su host diversi. È possibile utilizzare questi valori metrici per prendere decisioni basate sui dati che aiutano a evitare interruzioni della produzione e a pianificare l'infrastruttura.

La cardinalità è la combinazione di valori di tag univoci. Cerca di mantenere la cardinalità il più bassa possibile. Se l'applicazione richiede un identificatore univoco per ogni punto dati, utilizza i valori dei campi anziché i valori dei tag. Ciò si tradurrà in una latenza delle query significativamente migliore. Una buona progettazione dello schema può impedire una cardinalità di serie elevata, con conseguente miglioramento delle prestazioni delle query. [Se noti che le letture e le scritture dei dati rallentano o vuoi scoprire come la cardinalità influisce sulle prestazioni, consulta la documentazione di Timestream for InfluxDB.](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-getting-started-security-best-practices)

Se la tua applicazione emette oggetti JSON, convertili in singole colonne (tag o campi) e carica le colonne in InfluxDB. InfluxDB è progettato per dati di serie temporali, quindi organizzare i dati con singole colonne è la migliore pratica per sfruttare appieno le funzionalità del servizio.

Una singola istanza OSS InfluxDB v2.7 supporta circa 20 bucket InfluxDB che vengono scritti o interrogati attivamente in tutte le organizzazioni. Più di 20 bucket possono influire negativamente sulle prestazioni. Esistono dei limiti ad alcune opzioni di configurazione di InfluxDB e alcune opzioni che è possibile configurare in base al proprio caso d'uso. Convalida la configurazione in base al carico di lavoro dell'applicazione durante la fase di test. Le conservazioni dei dati sono configurate a livello di bucket, quindi i dati con requisiti di conservazione dei dati diversi devono essere archiviati in diversi bucket. [Per ulteriori informazioni sulle opzioni di configurazione, consulta la documentazione di Timestream for InfluxDB.](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-db-connecting.html#timestream-for-influx-parameter-groups)

Memorizza i dati nei valori dei tag o nei valori dei campi, non nelle chiavi dei tag, nelle chiavi di campo o nelle misurazioni. Se si progetta lo schema per memorizzare i dati in tag e valori di campo, le query saranno più facili da scrivere e più efficienti. Per altre best practice sulla modellazione dei dati, consulta [Progettazione per](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-getting-started-security-best-practices-design-for-performance) le prestazioni.

Utilizza [le attività di InfluxDB](https://docs.influxdata.com/influxdb/cloud/process-data/get-started/) per preaggregare i dati, caricarli in diverse misurazioni o bucket e generare dati per dashboard e visualizzazioni a partire da essi.

InfluxDB OSS espone un `/metrics` [endpoint](https://docs.influxdata.com/influxdb/v2/reference/internals/metrics/) che restituisce metriche di prestazioni, risorse e utilizzo formattate nel formato di esposizione in testo semplice Prometheus.**** Utilizza i modelli InfluxDB per configurare il [monitoraggio e gli avvisi per rilevare in modo proattivo problemi, come l'elevata latenza delle query, la](https://docs.influxdata.com/influxdb/v2/monitor-alert/templates/) riduzione della velocità di scrittura o i picchi di utilizzo delle risorse.

Timestream for InfluxDB fornisce lo spazio di archiviazione incluso in Influx IO. La selezione della dimensione IOPS appropriata può velocizzare notevolmente l'esecuzione delle query. Ciò è particolarmente utile per le query che devono scansionare grandi quantità di dati o gestire un'ampia gamma di richieste. In alcune situazioni, potrebbe essere necessaria una combinazione di scalabilità dell'istanza e miglioramento degli IOPS per ottenere i miglioramenti delle prestazioni desiderati.

Consigliamo di abbinare gli ambienti dev e prod (classe di istanza, tipo di storage, configurazioni). Verifica le modifiche nell'ambiente inferiore per ogni versione prima di passare alla produzione. Sui volumi di archiviazione Influx IO Included, Timestream for InfluxDB offre tre livelli di archiviazione preconfigurati con IOPS (3.000, 12.000, 16.000) e throughput ottimali richiesti per diversi tipi di carichi di lavoro. La maggior parte dei casi d'uso richiede meno di 3.000 IOPS. Scegli 12.000 o 16.000 solo se i test delle prestazioni indicano la necessità di IOPS elevati. Per ulteriori informazioni, consulta la [sezione Configurazione](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influxdb.html#timestream-for-influx-dbi-setting-up) nella documentazione di Timestream for InfluxDB.

## Ottimizza le scritture
<a name="optimize-writes"></a>

Per ottimizzare le scritture su InfluxDB, consigliamo di scrivere dati in batch di 5.000 righe di protocollo di linea per richiesta per ridurre al minimo il sovraccarico della rete. Per prestazioni migliori, ordina i tag per chiave in ordine lessicografico prima di scrivere i punti dati. Anche l'utilizzo della massima precisione temporale possibile per i timestamp, anziché i nanosecondi, può migliorare le prestazioni. L'attivazione della compressione gzip è un altro modo per velocizzare le scritture e ridurre la larghezza di banda della rete. Nella configurazione del plugin `influxdb_v2` di output `telegraf.conf` del tuo file, imposta l'`content_encoding`opzione su. `gzip` L'implementazione di queste ottimizzazioni può migliorare significativamente le prestazioni e l'efficienza della scrittura dei dati su InfluxDB. [Per ulteriori best practice di scrittura da InfluxDB, consulta Ottimizza le scritture su InfluxDB.](https://docs.influxdata.com/influxdb/v2/write-data/best-practices/optimize-writes/)

Le prestazioni di scrittura di InfluxDB sono spesso strettamente legate agli IOPS disponibili. Durante la scrittura dei dati, InfluxDB deve eseguire un numero significativo di operazioni di I/O per archiviare i dati. Quando aumenti gli IOPS, InfluxDB può elaborare più scritture al secondo.