Cuotas y límites

En esta página se detallan los límites de solicitudes y las cuotas de Cloud Storage.

Segmentos

  • Al crear y eliminar segmentos, hay un límite de frecuencia de aproximadamente 1 operación cada 2 segundos por proyecto. Por este motivo, en la mayoría de los casos, lo ideal es utilizar menos segmentos y más objetos. Por ejemplo, es habitual usar un segmento por cada usuario del proyecto. Sin embargo, si estás diseñando un sistema en el cual se añaden muchos usuarios por segundo o se crean objetos mediante credenciales automáticas, lo recomendable es que incluyas muchos usuarios en cada segmento (con sus permisos correspondientes) para que no se produzcan cuellos de botella debido al límite de frecuencia de creación de segmentos.

  • Las aplicaciones de alta disponibilidad no deben depender de la creación ni de la eliminación de segmentos en su ruta crítica. Los nombres de los segmentos forman parte de un espacio de nombres centralizado y global, y cualquier dependencia en él origina un punto único de fallo en la aplicación. Debido a esto (y al límite de 1 operación cada 2 segundos que hemos mencionado arriba), lo recomendable es crear previamente todos los segmentos necesarios para los servicios de alta disponibilidad en Cloud Storage.

  • Cada segmento se puede actualizar como máximo una vez por segundo, así que las actualizaciones rápidas en un único segmento (por ejemplo, cambiar la configuración del CORS) no se escalan.

  • Hay un límite de 100 miembros con roles antiguos de gestión de identidades y accesos por segmento.

Objetos

  • En Cloud Storage, el límite de tamaño máximo de cada objeto almacenado es de 5 TB.

  • Cada objeto se puede actualizar como máximo una vez por segundo. Así, las escrituras rápidas en un único objeto no se escalan. Para obtener más información, consulta el apartado sobre la inmutabilidad de los objetos en los términos clave.

  • No hay límite en cuanto al número de escrituras en varios objetos. Al principio, los segmentos admiten unas 1000 escrituras por segundo y, a partir de ahí, se escalan según sea necesario.

  • No hay límite de lecturas de un objeto. Al principio, los segmentos admiten unas 5000 lecturas por segundo y, a partir de ahí, se escalan según sea necesario.

  • El rendimiento de los objetos que se pueden almacenar en caché de forma pública es mucho mejor. Si utilizas un objeto para controlar a muchos clientes y te gustaría inhabilitar el almacenamiento en caché para proporcionar los datos más recientes, haz lo siguiente:

    • Prueba a configurar los metadatos Cache-Control del objeto como public, con un valor max-age de entre 15 y 60 segundos. La mayoría de las aplicaciones admiten un minuto de extensión y la tasa de resultados en caché mejora enormemente el rendimiento.

    • Lleva a cabo las transferencias de datos a través de una aplicación de Google App Engine que haga de intermediaria y que se encuentre en la misma ubicación que el segmento.

    • Utiliza Cache-Control: no-cache en los objetos para que, a partir de ese momento, no se guarden en caché cuando se realicen solicitudes de almacenamiento en las cachés perimetrales.

    Para obtener más información sobre las directivas de Cache-Control, consulta el apartado RFC 7234: Cache-Control.

  • Hay un límite de 100 entradas de la lista de control de acceso (LCA) por objeto.

  • En cuanto a la composición de objetos:

    • Cada solicitud de composición puede incluir un máximo de 32 objetos.

    • Aunque los objetos compuestos pueden tener un número ilimitado de componentes, sus metadatos componentCount asociados se saturan al llegar a 2.147.483.647.

    • El límite general de 5 TB para los objetos almacenados en Cloud Storage se aplica también a los objetos compuestos.

Solicitudes de API XML

  • Al enviar solicitudes a través de la API XML, el límite de tamaño combinado de la URL y de los encabezados HTTP de la solicitud es de 16 KB.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.