Cuotas y límites

En esta página, se describen las cuotas y los límites que se aplican a las solicitudes de Cloud Storage.

Depósitos

  • Existe una velocidad límite de aproximadamente una operación cada dos segundos por proyecto para la creación y eliminación de depósitos, por lo que es recomendable planificar el uso de menos depósitos y más objetos en la mayoría de los casos. Por ejemplo, en muchos diseños, se opta por usar un depósito por cada usuario del proyecto. Sin embargo, si vas a diseñar un sistema en el que se agregan varios usuarios por segundo, es recomendable que tu diseño use un mismo depósito para varios usuarios (con los permisos correspondientes), de modo que el límite de frecuencia que se aplica a la creación de depósitos no se convierta en un cuello de botella.

  • Las aplicaciones de alta disponibilidad no deberían depender de la creación o eliminación de depósitos para sus rutas críticas. Los nombres de los depósitos son parte de un espacio de nombres centralizado y global: cualquier dependencia de este espacio de nombres crea un punto único de falla para tu aplicación. Debido a esto y al límite de una operación cada dos segundos que se mencionó antes, se recomienda que los servicios de alta disponibilidad que usen Cloud Storage creen por adelantado todos los depósitos que vayan a necesitar.

  • Existe un límite de una actualización por segundo para cada depósito, por lo que las actualizaciones rápidas a un mismo depósito (p. ej., cambiar la configuración de CORS) no se escalan.

  • Existe un límite de 100 miembros con funciones de IAM heredadas por depósito. Los usuarios individuales, los grupos y los dominios son algunos ejemplos de miembros. Consulta las identidades de IAM.

  • Para depósitos con notificaciones de Pub/Sub:

    • El depósito puede tener hasta 100 configuraciones de notificación en total.

    • El depósito puede tener hasta 10 configuraciones de notificación definidas para activar un evento específico.

    • Cada configuración de notificación puede tener hasta 10 atributos personalizados.

Objetos

  • Existe un límite de tamaño de 5 TB como máximo para los objetos almacenados en Cloud Storage.

    • El tamaño máximo de una solicitud de carga única también es 5 TB. En el caso de las cargas que tardarán más tiempo en la conexión, considera usar cargas reanudables a fin de recuperarlas si ocurren fallas intermedias. Consulta Cargas reanudables para obtener más información.
  • Existe un límite de una actualización por segundo para cada objeto, por lo que las operaciones de escritura rápidas en un mismo objeto no se escalan. Para obtener más información, consulta Inmutabilidad de objetos en la lista de términos clave.

  • No se aplica ningún límite a las operaciones de escritura repartidas entre varios objetos, lo que incluye subir, actualizar y borrar objetos. En principio, los depósitos admiten alrededor de 1,000 operaciones de escritura por segundo, pero este límite se amplía según sea necesario.

  • No se aplica ningún límite a las operaciones de lectura de un objeto. En principio, los depósitos admiten alrededor de 5,000 operaciones de lectura de objetos por segundo, pero este límite se amplía según sea necesario.

  • El rendimiento es mucho mejor en el caso de los objetos que pueden almacenarse en caché públicamente. Si tienes un objeto que se usa para controlar muchos clientes y quieres inhabilitar el almacenamiento en caché a fin de que siempre se recuperen los datos más actualizados, sigue estas recomendaciones:

    • Tal vez sea mejor que configures los metadatos Cache-Control del objeto como public, con un valor de max-age de 15 a 60 segundos. La mayoría de las aplicaciones tolera un minuto de retraso y la tasa de aciertos de caché mejorará el rendimiento drásticamente.

    • Utiliza como proxy de las transferencias de datos una aplicación de Google App Engine que se encuentre en la misma ubicación que tu depósito.

    • Usa Cache-Control: no-cache en un objeto a fin de indicar que este no debe almacenarse en caché para solicitudes posteriores en el almacenamiento en caché perimetral.

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

  • Existe un límite de 100 entradas en la Lista de control de acceso (LCA) por objeto. Los miembros pueden ser usuarios individuales, grupos o dominios. Consulta los alcances de LCA.

  • Para la composición de objetos:

    • Se pueden componer hasta 32 objetos en una misma solicitud de composición.

    • Si bien no existe un límite para la cantidad de componentes de un objeto compuesto, los metadatos componentCount asociados se saturan en 2,147,483,647.

    • Los objetos compuestos están sujetos al límite de tamaño de 5 TB aplicable a los objetos almacenados en Cloud Storage.

Solicitudes a la API de XML

  • Cuando envías solicitudes mediante la API de XML, se aplica un límite de 16 KB al tamaño combinado de la URL de la solicitud y los encabezados HTTP.

  • Cuando haces una lista de recursos mediante la API de XML, se aplica un límite de 1,000 a los elementos que se van a mostrar.

Claves HMAC para cuentas de servicio

  • Existe un límite de 5 claves HMAC por cuenta de servicio. Las claves borradas no se consideran en este límite.