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à. # Prevenire la limitazione (della larghezza di banda della rete) di Amazon S3 La limitazione (della larghezza di banda della rete) è il processo di limitazione della velocità con cui utilizzi un servizio, un'applicazione o un sistema. Inoltre AWS, puoi utilizzare la limitazione per evitare un uso eccessivo del servizio Amazon S3 e aumentare la disponibilità e la reattività di Amazon S3 per tutti gli utenti. Tuttavia, poiché la limitazione limitazione (della larghezza di banda della rete) riduce la velocità con cui i dati possono essere trasferiti da o verso Amazon S3, è importante tenere a mente di evitare che le interazioni siano limitate. Come indicato nel capitolo sull’[ottimizzazione delle prestazioni](performance-tuning.md), le ottimizzazioni possono dipendere dalle decisioni prese a livello di servizio, dalla struttura delle tabelle e dei dati e dalla modalità di scrittura delle query. **Topics** + [Riduzione della limitazione (della larghezza di banda della rete) a livello di servizio](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md) + [Ottimizzare le tabelle](performance-tuning-s3-throttling-optimizing-your-tables.md) + [Ottimizzare le query](performance-tuning-s3-throttling-optimizing-queries.md) # Riduzione della limitazione (della larghezza di banda della rete) a livello di servizio Per evitare la limitazione (della larghezza di banda della rete) di Amazon S3 a livello di servizio, puoi monitorare l'utilizzo e modificare le [service quotas](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3) oppure puoi utilizzare determinate tecniche, come il partizionamento. Di seguito sono riportate alcune delle condizioni che possono portare alla limitazione (della larghezza di banda della rete): + **Superamento dei limiti di richiesta API da parte del tuo account**: Amazon S3 ha limiti di richiesta API predefiniti basati sul tipo di account e sull'utilizzo. Se per un singolo prefisso viene superato il numero massimo di richieste al secondo, le tue richieste potrebbero essere sottoposte alle limitazione (della larghezza di banda della rete) per evitare il sovraccarico del servizio Amazon S3. + **Partizionamento insufficiente dei dati**: se non partizioni correttamente i dati e trasferisci una grande quantità di dati, Amazon S3 può limitare le richieste. Per ulteriori informazioni sul partizionamento, consulta la sezione [Utilizzo del partizionamento](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) in questo documento. + **Numero elevato di oggetti di piccole dimensioni**: se possibile, evita molti file di piccole dimensioni. Amazon S3 ha un limite di [5500 richieste GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) al secondo per prefisso partizionato e le tue query Athena hanno lo stesso limite. Se in una singola query analizzi milioni di oggetti di piccole dimensioni, è probabile che la tua query venga limitata da Amazon S3. Per evitare un eccesso di scansione, puoi utilizzare AWS Glue ETL per compattare periodicamente i file oppure partizionare la tabella e aggiungere filtri per le chiavi di partizione. Per ulteriori informazioni, consulta le risorse seguenti. + [Come posso configurare un processo AWS Glue ETL per generare file più grandi?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*Centro di AWS conoscenza*) + [Leggere i file di input in gruppi più grandi](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Guida per AWS Glue gli sviluppatori*) # Ottimizzare le tabelle La strutturazione dei dati è importante in caso di problemi di limitazione (della larghezza di banda della rete). Sebbene Amazon S3 sia in grado di gestire grandi quantità di dati, talvolta sopraggiunge una limitazione (della larghezza di banda della rete) a causa del modo in cui i dati sono strutturati. Le sezioni seguenti mostrano alcuni suggerimenti su come strutturare i dati in Amazon S3 per evitare problemi di limitazione (della larghezza di banda della rete). ## Utilizzo del partizionamento Puoi utilizzare il partizionamento per ridurre le limitazioni (della larghezza di banda della rete) contenendo la quantità di dati a cui accedere in un dato momento. Partizionando i dati su colonne specifiche, puoi distribuire le richieste in modo uniforme su più oggetti e ridurre il numero di richieste per un singolo oggetto. La riduzione della quantità di dati da analizzare migliora le prestazioni delle query e riduce i costi. Quando crei una tabella, puoi definire le partizioni che fungono da colonne virtuali. Per creare una tabella con partizioni in una dichiarazione `CREATE TABLE`, utilizza la clausola `PARTITIONED BY (column_name data_type)` in modo da definire le chiavi per partizionare i dati. Per limitare le partizioni analizzate da una query, puoi specificarle come predicati in una clausola `WHERE` della query. Pertanto, le colonne utilizzate frequentemente come filtri sono adatte al partizionamento. In genere è consigliabile partizionare i dati in base agli intervalli di tempo, il che spesso determina uno schema di partizionamento a più livelli. Nota che anche per il partizionamento sono previsti dei costi. Quando aumenti il numero di partizioni nella tabella, viene aumentato anche il tempo necessario a recuperare ed elaborare i metadati delle partizioni. Pertanto, un partizionamento eccessivo può eliminare i vantaggi derivanti da un partizionamento più oculato. Se i dati sono fortemente disallineati rispetto a un valore di partizione e la maggior parte delle query utilizza tale valore, potresti andare incontro a un sovraccarico aggiuntivo. Per ulteriori informazioni sul partizionamento in Athena, consulta [Cos'è il partizionamento?](ctas-partitioning-and-bucketing-what-is-partitioning.md). ## Come raggruppare i dati nel bucket Un altro modo per partizionare i dati consiste nel raggrupparli in bucket all'interno di una singola partizione. Per raggruppare dati nel bucket specifica una o più colonne che contengono le righe che vuoi raggruppare insieme. Quindi sistema quelle righe in più bucket. In questo modo puoi eseguire una query solo sul bucket da leggere, il che riduce il numero di righe di dati da analizzare. Quando selezioni una colonna da utilizzare per il raggruppamento in bucket, seleziona la colonna con cardinalità elevata (ovvero con molti valori distinti), che è distribuita uniformemente e che viene spesso utilizzata per filtrare i dati. Un esempio di colonna valida da utilizzare per il raggruppamento in bucket è una chiave primaria, ad esempio una colonna di ID. Per ulteriori informazioni sul raggruppamento in bucket su Athena, consulta [Cos'è il raggruppamento in bucket?](ctas-partitioning-and-bucketing-what-is-bucketing.md). ## Usa gli AWS Glue indici di partizione È possibile utilizzare gli indici di AWS Glue partizione per organizzare i dati in una tabella in base ai valori di una o più partizioni. AWS Glue gli indici di partizione possono ridurre il numero di trasferimenti di dati, la quantità di elaborazione dei dati e il tempo di elaborazione delle query. Un indice di AWS Glue partizione è un file di metadati che contiene informazioni sulle partizioni della tabella, incluse le chiavi di partizione e i relativi valori. L'indice delle partizioni viene archiviato in un bucket Amazon S3 e viene aggiornato automaticamente non appena vengono AWS Glue aggiunte nuove partizioni alla tabella. Quando è presente un indice di AWS Glue partizione, le query tentano di recuperare un sottoinsieme delle partizioni invece di caricare tutte le partizioni della tabella. Le query sono eseguite solo sul sottoinsieme di dati rilevante per la query. Quando si crea una tabella in AWS Glue, è possibile creare un indice di partizione su qualsiasi combinazione di chiavi di partizione definite nella tabella. Dopo aver creato uno o più indici di partizione su una tabella, è necessario aggiungere una proprietà alla tabella che abiliti il filtraggio delle partizioni. Quindi, puoi eseguire query sulla tabella da Athena. *Per informazioni sulla creazione di indici di partizione in AWS Glue, consulta [Working with partition indexes](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) nella Developer Guide. AWS GlueAWS Glue * Per informazioni su come aggiungere una proprietà di tabella per abilitare il filtraggio delle partizioni, consulta [Ottimizza le query con l'indicizzazione e il AWS Glue filtraggio delle partizioni](glue-best-practices-partition-index.md). ## Come utilizzare la compressione di dati e la suddivisione dei file La compressione dei dati può velocizzare le query in maniera significativa se i file hanno dimensioni ottimali o se possono essere suddivisi in gruppi logici. In genere, i rapporti di compressione più elevati richiedono più cicli di CPU per comprimere e decomprimere i dati. Per Athena, è consigliabile utilizzare Apache Parquet o Apache ORC, che comprimono i dati per impostazione predefinita. Per ulteriori informazioni sulla compressione dei dati in Athena, consulta [Usa la compressione in Athena](compression-formats.md). La suddivisione dei file aumenta il parallelismo consentendo ad Athena di distribuire il processo di lettura di un singolo file tra più lettori. Se un singolo file non è suddivisibile, può leggerlo solo un lettore mentre gli altri lettori sono inattivi. Apache Parquet e Apache ORC supportano anche i file suddivisibili. ## Utilizzo di archivi dati colonnari ottimizzati Le prestazioni delle query Athena migliorano in modo significativo se converti i dati in un formato colonnare. Quando generi file colonnari, una tecnica di ottimizzazione da considerare consiste nell'ordinare i dati in base alla chiave di partizione. Apache Parquet e Apache ORC sono gli archivi dati colonnari e open source comunemente utilizzati. Per informazioni sulla conversione dell'origine dati esistente di Amazon S3 in uno di questi formati, consulta [Converti in formati colonnari](columnar-storage.md#convert-to-columnar). ### Utilizzo di una dimensione di blocco Parquet o di una dimensione di stripe ORC maggiore Parquet e ORC dispongono di parametri di archiviazione di dati che puoi regolare per l'ottimizzazione. In Parquet, puoi ottimizzare la dimensione dei blocchi. In ORC, puoi ottimizzare la dimensione delle stripe. Più grande è il blocco o la stripe, maggiore è il numero di righe che puoi memorizzare in ciascuno di essi. Per impostazione predefinita, la dimensione del blocco Parquet è di 128 MB e la dimensione della stripe ORC è di 64 MB. Se una stripe ORC è inferiore a 8 MB (il valore predefinito di `hive.orc.max_buffer_size`), Athena legge l'intera stripe ORC. Questo è il compromesso a cui Athena scende tra la selettività delle colonne e le operazioni di input/output al secondo per stripe di dimensioni inferiori. Se hai tabelle con un numero molto elevato di colonne, dimensioni ridotte di blocchi o stripe possono comportare una scansione di più dati di quanto sia necessario. In questi casi, le dimensioni maggiori di un blocco possono essere più efficienti. ### Utilizzo di ORC per tipi complessi Al momento, quando esegui una query su colonne archiviate in Parquet con tipi di dati complessi (`array`, `map` o `struct`), Athena legge un'intera riga di dati anziché leggere selettivamente solo le colonne specificate. Si tratta di un problema noto di Athena. Per ovviare al problema, prendi in considerazione la possibilità di utilizzare ORC. ### Scelta di un algoritmo di compressione Un altro parametro che puoi configurare è l'algoritmo di compressione sui blocchi di dati. Per informazioni sugli algoritmi di compressione supportati per Parquet e ORC in Athena, consulta [Supporto della compressione Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html). Per ulteriori informazioni sull'ottimizzazione dei formati di storage a colonne in Athena, consulta la sezione «Ottimizzazione della generazione di archivi dati a colonne» nel post del blog AWS Big Data I [10 migliori](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) consigli per l'ottimizzazione delle prestazioni per Amazon Athena. ## Utilizzo delle tabelle Iceberg Apache Iceberg è un formato a tabella aperta per set di dati analitici di dimensioni molto grandi concepito per un utilizzo ottimizzato su Amazon S3. Puoi usare le tabelle Iceberg per ridurre la limitazione (della larghezza di banda della rete) in Amazon S3. Le tabelle Iceberg ti offrono i seguenti vantaggi: + Puoi partizionare le tabelle Iceberg su una o più colonne. Ciò ottimizza l'accesso ai dati e riduce la quantità di dati che le query devono scansionare. + La modalità di archiviazione di oggetti Iceberg, poiché ottimizza l'utilizzo delle tabelle Iceberg in Amazon S3, può elaborare grandi volumi di dati e carichi di lavoro di query pesanti. + Le tabelle Iceberg in modalità di archiviazione di oggetti sono scalabili, resistenti agli errori e durevoli, il che può aiutare a ridurre la limitazione (della larghezza di banda della rete). + Con il supporto delle transazioni ACID più utenti possono aggiungere ed eliminare oggetti Amazon S3 in modo atomico. Per ulteriori informazioni su Apache Iceberg, consulta [Apache Iceberg](https://iceberg.apache.org/). Per informazioni sull'utilizzo delle tabelle Apache Iceberg in Athena, consulta la sezione [Utilizzo delle tabelle Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html). # Ottimizzare le query Utilizza i suggerimenti di questa sezione per ottimizzare le query SQL in Athena. ## Utilizza LIMIT con la clausola ORDER BY La clausola `ORDER BY` restituisce i dati disponendoli in ordine. Ciò richiede che Athena invii tutte le righe di dati a un singolo nodo worker e che quindi ordini le righe. Questo tipo di query può essere eseguito a lungo o addirittura non andare a buon fine. Per una maggiore efficienza delle query, esamina i *N* valori iniziali o inferiori, quindi utilizza anche una clausola. `LIMIT` Ciò riduce in modo significativo il costo dell'ordinamento, inviando sia l'ordinamento sia le restrizioni ai singoli nodi worker anziché a un singolo worker. ## Ottimizzazione delle clausole JOIN Quando effettui il join di due tabelle, Athena distribuisce la tabella a destra ai nodi worker, quindi trasmette la tabella a sinistra per eseguire il join. Per questo motivo, specifica la tabella di maggiori dimensioni sul lato sinistro del join e la tabella di dimensioni inferiori sul lato destro del join. In questo modo, Athena utilizza meno memoria ed esegue la query con una latenza inferiore. Inoltre, nota quanto segue: + Quando utilizzi più comandi `JOIN`, specifica le tabelle dalla più grande alla più piccola. + Evita i cross join a meno che non siano richiesti dalla query. ## Ottimizzazione delle clausole GROUP BY L'operatore `GROUP BY` distribuisce le righe ai nodi worker in base alle colonne `GROUP BY`. Queste colonne hanno un riferimento in memoria e i valori sono confrontati man mano che le righe sono acquisite. I valori sono aggregati insieme quando si trova una corrispondenza con la colonna `GROUP BY`. Considerando il modo di funzionamento di questo processo, è consigliabile ordinare le colonne dalla cardinalità più alta a quella più bassa. ## Utilizzo di numeri anziché di stringhe Poiché i numeri richiedono meno memoria e sono più veloci da elaborare rispetto alle stringhe, se possibile utilizza numeri anziché stringhe. ## Limitazione del numero di colonne Per ridurre la quantità totale di memoria necessaria per archiviare i dati, limita il numero di colonne specificato nella dichiarazione `SELECT`. ## Utilizzo di espressioni regolari anziché di LIKE Le query che includono clausole quali `LIKE '%string%'` su stringhe di grandi dimensioni possono essere molto intense dal punto di vista computazionale. Quando filtri in base a più valori su una colonna di stringhe, utilizza la funzione [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) e un'espressione regolare. Ciò è particolarmente utile quando confronti un lungo elenco di valori. ## Utilizzo della clausola LIMIT Quando esegui una query, anziché selezionare tutte le colonne, puoi utilizzare la clausola `LIMIT` per restituire solo le colonne necessarie. In questo modo si riducono le dimensioni del set di dati elaborato tramite la pipeline di esecuzione delle query. Le clausole `LIMIT` sono più utili quando esegui query su tabelle con un gran numero di colonne basate su stringhe. Le clausole `LIMIT` sono utili anche quando esegui più join o aggregazioni sulle query.