# Evitar la limitación de Amazon S3
La limitación es el proceso de limitar la velocidad a la que se utiliza un servicio, una aplicación o un sistema. En AWS, se puede utilizar la limitación para evitar el uso excesivo del servicio Amazon S3 y aumentar la disponibilidad y la capacidad de respuesta de Amazon S3 para todos los usuarios. Sin embargo, dado que la limitación limita la velocidad a la que se pueden transferir los datos hacia Amazon S3 o desde este, es importante considerar la posibilidad de evitar que se limiten las interacciones.
Como se señaló en el capítulo sobre el [ajuste del rendimiento](performance-tuning.md), las optimizaciones pueden depender de las decisiones para cada servicio, de la forma en que se estructuran las tablas y los datos y de la forma en que se escriben las consultas.
**Topics**
+ [Reduzca las limitaciones a nivel de servicio](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md)
+ [Optimización de las tablas](performance-tuning-s3-throttling-optimizing-your-tables.md)
+ [Optimización de las consultas](performance-tuning-s3-throttling-optimizing-queries.md)
# Reduzca las limitaciones a nivel de servicio
Para evitar que Amazon S3 se limite a nivel de servicio, puede supervisar el uso y ajustar las [cuotas de servicio](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3), o bien utilizar determinadas técnicas, como las particiones. A continuación, se detallan algunas de las condiciones que pueden provocar la limitación:
+ **Superar los límites de solicitudes de la API de su cuenta**: Amazon S3 tiene límites de solicitudes de API predeterminados que se basan en el tipo de cuenta y el uso. Si supera el número máximo de solicitudes por segundo para un solo prefijo, es posible que sus solicitudes se limiten para evitar la sobrecarga del servicio Amazon S3.
+ **Partición insuficiente de los datos**: si no particiona correctamente los datos y transfiere una gran cantidad de datos, Amazon S3 puede limitar sus solicitudes. Para obtener más información sobre las particiones, consulte la sección [Utilice particiones](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) mencionada en este documento.
+ **Gran cantidad de objetos pequeños**: si es posible, evite tener una gran cantidad de archivos pequeños. Amazon S3 tiene un límite de [5500 solicitudes GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) por segundo por prefijo particionado y las consultas de Athena tienen este mismo límite. Si analiza millones de objetos pequeños en una sola consulta, Amazon S3 puede limitar la consulta.
Para evitar un análisis excesivo, utilice ETL de AWS Glue para compactar periódicamente los archivos o particionar la tabla y agregar filtros de clave de partición. Para obtener más información, consulte los siguientes recursos.
+ [¿Cómo puedo configurar un trabajo de ETL en AWS Glue para generar archivos más grandes?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*AWS Centro de conocimientos de*)
+ [Lectura de archivos de entrada en grupos más grandes](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Guía para desarrolladores de AWS Glue*)
# Optimización de las tablas
Si tiene problemas de limitación, es importante que estructure los datos. Si bien Amazon S3 puede gestionar grandes cantidades de datos, a veces se produce una limitación debido a la forma en que están estructurados los datos.
En las siguientes secciones se ofrecen algunas sugerencias sobre cómo estructurar los datos en Amazon S3 para evitar problemas de limitación.
## Utilice particiones
Puede utilizar las particiones para reducir la limitación al limitar la cantidad de datos a los que se puede acceder en cualquier momento. Al dividir los datos en columnas específicas, puede distribuir las solicitudes de manera uniforme entre varios objetos y reducir el número de solicitudes de un solo objeto. Al reducir la cantidad de datos que se deben analizar, el rendimiento de las consultas mejora y los costos se reducen.
Al crear una tabla, puede definir particiones, que actúan como columnas virtuales. Para crear una tabla con particiones en una instrucción `CREATE TABLE`, utilice la cláusula `PARTITIONED BY (column_name data_type)` a fin de definir las claves para dividir los datos.
Para restringir las particiones analizadas en una consulta, puede especificarlas como predicados en una cláusula `WHERE` de la consulta. De esta manera, las columnas que se utilizan con frecuencia como filtros son buenas candidatas para la creación de particiones. Una práctica común consiste en particionar los datos en función de intervalos de tiempo, lo que puede dar lugar a un esquema de particiones de varios niveles.
Tenga en cuenta que la creación de particiones también tiene un costo. Al aumentar el número de particiones de la tabla, también aumenta el tiempo necesario para recuperar y procesar los metadatos de las particiones. Por lo tanto, la sobrepartición puede eliminar los beneficios que se obtienen al particionar con un mejor criterio. Si sus datos están muy sesgados hacia un valor de partición y la mayoría de las consultas utilizan ese valor, es posible que incurra en una sobrecarga adicional.
Para obtener más información sobre la creación de particiones en Athena, consulte [¿Qué es la creación de particiones?](ctas-partitioning-and-bucketing-what-is-partitioning.md).
## Organice los datos en buckets
Otra forma de particionar los datos consiste en organizarlos en buckets en una sola partición. Al organizar los datos en buckets, especifica una o más columnas que contienen las filas que desea agrupar. A continuación, pone esas filas en varios buckets. De esta forma, solo consulta el bucket que debe leerse, lo que reduce el número de filas de datos que deben analizarse.
Al seleccionar una columna para utilizarla en los buckets, seleccione la columna que tenga una cardinalidad alta (es decir, que tenga muchos valores distintos), que esté distribuida de manera uniforme y que se utilice con frecuencia para filtrar los datos. Un ejemplo de una buena columna que se puede usar para organizar datos en buckets es una clave principal, como una columna de ID.
Para obtener más información acerca de la asignación de buckets en Athena, consulte [¿Qué es la asignación de buckets?](ctas-partitioning-and-bucketing-what-is-bucketing.md).
## Utilice índices de particiones de AWS Glue
Puede usar índices de partición de AWS Glue para organizar los datos de una tabla en función de los valores de una o más particiones. Los índices de partición de AWS Glue pueden reducir el número de transferencias de datos, la cantidad de procesamiento de datos y el tiempo de procesamiento de las consultas.
Un índice de particiones de AWS Glue es un archivo de metadatos que contiene información sobre las particiones de la tabla, incluidas las claves de partición y sus valores. El índice de particiones se almacena en un bucket de Amazon S3 y AWS Glue lo actualiza automáticamente a medida que se agregan nuevas particiones a la tabla.
Cuando un índice de particiones de AWS Glue está presente, las consultas pueden recuperar un subconjunto de las particiones en lugar de cargar todas las particiones de la tabla. Las consultas solo se ejecutan en el subconjunto de datos que es relevante para la consulta.
Al crear una tabla en AWS Glue, puede crear un índice de particiones en cualquier combinación de claves de partición definidas en la tabla. Tras crear uno o más índices de partición en una tabla, debe agregar una propiedad a la tabla que permita el filtrado de particiones. A continuación, puede consultar la tabla desde Athena.
Para obtener información acerca de cómo crear índices de particiones en AWS Glue, consulte [Trabajar con índices de partición en AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) en la *Guía para desarrolladores de AWS Glue*. Para obtener información sobre cómo agregar una propiedad de tabla para habilitar el filtrado de particiones, consulte [Optimización de las consultas con indexación y filtrado de particiones de AWS Glue](glue-best-practices-partition-index.md).
## Utilice la compresión de datos y la división de archivos
La compresión de datos puede acelerar de forma significativa las consultas si los archivos tienen el tamaño óptimo o si se pueden dividir en grupos lógicos. Por lo general, las relaciones de compresión más altas requieren más ciclos de CPU para comprimir y descomprimir los datos. Para Athena, se recomienda utilizar Apache Parquet o Apache ORC, que comprimen los datos de forma predeterminada. Para obtener información sobre la compresión de datos en Athena, consulte [Uso de la compresión en Athena](compression-formats.md).
La división de archivos aumenta el paralelismo al permitir que Athena distribuya la tarea de leer un solo archivo entre varios lectores. Si un único archivo no se puede dividir, solo un único lector puede leerlo mientras los demás lectores permanecen inactivos. Apache Parquet y Apache ORC también admiten la división de archivos.
## Utilice almacenes de datos en columnas optimizados
El rendimiento de las consultas de Athena mejora de forma significativa si convierte los datos a un formato de columnas. Al generar archivos en columnas, una técnica de optimización a tener en cuenta es ordenar los datos en función de la clave de partición.
Apache Parquet y Apache ORC son almacenes de datos en columnas de código abierto cuyo uso está generalizado. Para obtener información sobre cómo convertir un origen de datos de Amazon S3 existente a uno de estos formatos, consulte [Conversión a formatos de columnas](columnar-storage.md#convert-to-columnar).
### Utilice un tamaño de bloque de Parquet o de banda de ORC más grande
Parquet y ORC tienen parámetros de almacenamiento de datos que puede ajustar para su optimización. En Parquet, puede optimizar el tamaño del bloque. En ORC, puede optimizar el tamaño de las bandas. Cuanto más grande sea el bloque o la banda, más filas podrá almacenar en cada uno. De forma predeterminada, el tamaño del bloque de Parquet es de 128 MB y el tamaño de la banda de ORC es de 64 MB.
Si una banda de ORC ocupa menos de 8 MB (el valor predeterminado de `hive.orc.max_buffer_size`), Athena lee toda la banda de ORC. Esta es la compensación que Athena hace entre la selectividad de columnas y las operaciones de entrada/salida por segundo para bandas más pequeñas.
Si tiene tablas con un gran número de columnas, un tamaño de bloque o banda pequeño puede provocar que se analicen más datos de los necesarios. En estos casos, un tamaño de bloque más grande puede ser más eficiente.
### Utilice ORC para tipos complejos
Actualmente, cuando se consultan columnas almacenadas en Parquet con tipos de datos complejos (por ejemplo, `array`, `map` o `struct`), Athena lee toda una fila de datos, en lugar de leer solo de manera selectiva las columnas especificadas. Este es un problema conocido en Athena. Como solución, considere usar ORC.
### Elija un algoritmo de compresión
Otro parámetro que puede configurar es el algoritmo de compresión de los bloques de datos. Para obtener información sobre los algoritmos de compresión compatibles con Parquet y ORC en Athena, consulte [Compatibilidad con la compresión de Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html).
Para obtener más información sobre la optimización de los formatos de almacenamiento en columnas en Athena, consulte la sección “Optimizar la generación de almacenes de datos en columnas” en la publicación del Blog de macrodatos de AWS [Top 10 Performance Tuning Tips for Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) (Los 10 mejores consejos para ajustar el rendimiento de Amazon Athena).
## Utilice tablas de Iceberg
Apache Iceberg es un formato de tabla de código abierto para conjuntos de datos analíticos de gran tamaño diseñado para el uso optimizado en Amazon S3. Puede usar tablas de Iceberg para ayudar a reducir las limitaciones en Amazon S3.
Las tablas de Iceberg ofrecen las siguientes ventajas:
+ Puede dividir las tablas de Iceberg en una o más columnas. Esto optimiza el acceso a los datos y reduce la cantidad de datos que se deben analizar en las consultas.
+ Como el modo de almacenamiento de objetos de Iceberg optimiza las tablas de Iceberg para que funcionen con Amazon S3, puede procesar grandes volúmenes de datos y cargas de trabajo de consultas pesadas.
+ Las tablas de Iceberg en el modo de almacenamiento de objetos son escalables, tolerantes a errores y duraderas, lo que puede ayudar a reducir las limitaciones.
+ La compatibilidad con transacciones ACID significa que varios usuarios pueden agregar y eliminar objetos de Amazon S3 de forma atómica.
Para obtener más información sobre Apache Iceberg, consulte [Apache Iceberg](https://iceberg.apache.org/). Para obtener información acerca del uso de tablas de Apache Iceberg en Athena, consulte [Utilización de tablas de Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html).
# Optimización de las consultas
Utilice las sugerencias de esta sección para optimizar sus consultas SQL en Athena.
## Utilice LIMIT con la cláusula ORDER BY
La cláusula `ORDER BY` devuelve los datos en un orden clasificado Esto requiere que Athena envíe todas las filas de datos a un único nodo de trabajo y luego las ordene. Este tipo de consulta puede ejecutarse durante mucho tiempo o, incluso, fallar.
Para aumentar la eficacia de las consultas, observe los valores *N* en la parte superior o inferior y utilice también una cláusula `LIMIT`. Esto reduce de forma significativa el costo de la clasificación, ya que tanto la clasificación como la limitación recaen en nodos de trabajo individuales en lugar de en un solo trabajo.
## Optimice las cláusulas JOIN
Al unir dos tablas, Athena distribuye la tabla de la derecha entre los nodos de trabajo y luego incluye la tabla de la izquierda para realizar la unión.
Por este motivo, especifique la tabla más grande en el lado izquierdo de la unión y la tabla más pequeña en el lado derecho de la unión. De esta forma, Athena utiliza menos memoria y ejecuta la consulta con una latencia menor.
También tenga en cuenta los siguientes puntos:
+ Cuando utilice varios comandos `JOIN`, especifique las tablas de mayor a menor.
+ Evite las uniones cruzadas a menos que la consulta las requiera.
## Optimice las cláusulas GROUP BY
El operador `GROUP BY` distribuye las filas en función de las columnas `GROUP BY` a los nodos de trabajo. Se hace referencia a estas columnas en la memoria y los valores se comparan a medida que se ingieren las filas. Los valores se agregan cuando la columna `GROUP BY` coincide. Teniendo en cuenta la forma en que funciona este proceso, se recomienda ordenar las columnas desde la cardinalidad más alta hasta la más baja.
## Utilice números en lugar de cadenas
Como los números requieren menos memoria y son más rápidos de procesar en comparación con las cadenas, utilice números en lugar de cadenas siempre que sea posible.
## Limite el número de columnas
A fin de reducir la cantidad total de memoria necesaria para almacenar los datos, limite el número de columnas especificado en la instrucción `SELECT`.
## Utilice expresiones comunes en lugar de LIKE
Las consultas que incluyen cláusulas como `LIKE '%string%'` en cadenas grandes pueden ser muy exigentes desde el punto de vista computacional. Al filtrar varios valores en una columna de cadena, utilice la función [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) y una expresión común en su lugar. Esto resulta muy útil cuando se compara una lista larga de valores.
## Utilice la cláusula LIMIT
En lugar de seleccionar todas las columnas al ejecutar una consulta, utilice la cláusula `LIMIT` para devolver solo las columnas que necesite. Esto reduce el tamaño del conjunto de datos que se procesa a través de la canalización de ejecución de la consulta. Las cláusulas `LIMIT` son más útiles cuando se consultan tablas que tienen un gran número de columnas basadas en cadenas. Las cláusulas `LIMIT` también son útiles cuando se realizan múltiples uniones o agregaciones en cualquier consulta.