Cuotas y límites

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

Depósitos

  • Existe una velocidad límite de aproximadamente 1 operación cada 2 segundos por proyecto para la creación y eliminación de depósitos, por lo que es recomendable planificar a fin de usar 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 o que crea objetos con credenciales robóticas, 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 velocidad 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 fallo para tu aplicación. Debido a esto y al límite de 1 operación cada 2 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 100 miembros con funciones de IAM heredadas por depósito.

Objetos

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

  • 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 son escalables. Para obtener más información, consulta Inmutabilidad de los objetos en la lista de Términos clave.

  • No se aplica ningún límite a las operaciones de escritura repartidas entre varios objetos. En principio, los depósitos admiten unas 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 unas 5,000 operaciones de lectura 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 toleran un minuto de retraso y la tasa de acierto de caché mejorará el rendimiento drásticamente.

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

    • Usa Cache-Control: no-cache en un objeto para 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 la sección sobre el control de caché en RFC 7234.

  • Existe un límite de 100 entradas en la Lista de control de acceso (LCA) por objeto.

  • Para la composición de objetos:

    • Se pueden componer hasta 32 objetos en una sola 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 para los objetos almacenados en Cloud Storage.

Solicitudes en 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.
¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

¿Necesitas ayuda? Visita nuestra página de asistencia.