Quota en limieten

Op deze pagina worden quota en verzoeklimieten voor Cloud Storage behandeld.

Buckets

  • Er geldt een limiet per project voor het maken en verwijderen van buckets van ongeveer 1 bewerking per 2 seconden, dus in de meeste gevallen moet u rekenen met minder buckets en meer objecten. Er wordt bijvoorbeeld vaak voor een opzet gekozen waarbij per gebruiker van uw project één bucket wordt gebruikt. Als u echter een systeem ontwerpt waarbij per seconde veel gebruikers worden toegevoegd of waarbij objecten worden gemaakt met behulp van robotgegevens, kunt u het beste een ontwerp voor veel gebruikers in één bucket (met de juiste rechten) maken, zodat er geen problemen ontstaan door de limiet voor het maken van buckets.

  • Apps met een hoge beschikbaarheid mogen in het kritieke pad niet afhankelijk zijn van het maken of verwijderen van buckets. Bucketnamen maken deel uit van een gecentraliseerde en wereldwijde naamruimte: afhankelijkheid van deze naamruimte kan voor uw app tot problemen leiden. Om deze reden, en vanwege de hierboven vermelde limiet van 1 bewerking per 2 seconden, wordt voor services met een hoge beschikbaarheid in Cloud Storage aanbevolen om vooraf alle benodigde buckets te maken.

  • Voor elke bucket geldt een updatelimiet van eenmaal per seconde, dus snelle updates van een enkele bucket (bijvoorbeeld wijzigingen van de CORS-configuratie) worden niet geschaald.

  • Er geldt een limiet van 100 leden met verouderde IAM-rollen per bucket.

Objecten

  • Er geldt een maximale grootte van 5 TB voor afzonderlijke objecten die zijn opgeslagen in Cloud Storage.

  • Voor elk object geldt een updatelimiet van eenmaal per seconde, dus snelle schrijfbewerkingen naar een enkel object worden niet geschaald. Zie Onveranderbaarheid van objecten in Belangrijke termen voor meer informatie.

  • Er is geen limiet voor schrijfbewerkingen naar meerdere objecten, inclusief het uploaden, updaten en verwijderen van objecten. Buckets ondersteunen aanvankelijk ruwweg 1000 schrijfbewerkingen per seconde en worden vervolgens voor zover nodig geschaald.

  • Er is geen limiet voor leesbewerkingen van objecten. Buckets ondersteunen aanvankelijk ruwweg 5000 leesbewerkingen per seconde en worden vervolgens voor zover nodig geschaald.

  • De prestaties zijn veel beter voor objecten die in het openbare cachegeheugen kunnen worden opgeslagen. Als u een object gebruikt om veel clients te beheren en u het cachegeheugen wilt uitschakelen om de nieuwste gegevens te kunnen leveren, doet u het volgende:

    • Stel in plaats daarvan de Cache-Control-metadata van het object in op public met max-age van 15-60 seconden. De meeste apps zijn geschikt voor een spreiding van 1 minuut en door de aanwezigheid in het cachegeheugen worden de prestaties aanzienlijk verbeterd.

    • Kies voor overdracht van proxygegevens via een Google App Engine-app die zich op dezelfde locatie bevindt als uw bucket.

    • Gebruik Cache-Control: no-cache voor objecten om aan te geven dat het object voor volgende aanvragen in edge-caches niet in het cachegeheugen mag worden opgeslagen.

    Zie RFC 7234: Cache-Control voor meer informatie over Cache-Control-richtlijnen.

  • Er geldt een limiet van 100 vermeldingen op de toegangscontrolelijst (Access Control List, ACL) per object.

  • Voor objectsamenstelling:

    • Er kunnen maximaal 32 objecten worden samengesteld in één samenstellingsverzoek.

    • Hoewel er geen limiet is voor het aantal componenten waaruit een samengesteld object kan bestaan, zijn de componentCount-metagegevens van een samengesteld object verzadigd bij 2.147.483.647.

    • Samengestelde objecten vallen onder de algemene groottelimiet van 5 TB voor objecten die zijn opgeslagen in Cloud Storage.

XML API-verzoeken

  • Bij het verzenden van verzoeken via de XML API geldt een limiet van 16 KB voor de gecombineerde grootte van de URL en HTTP-headers van het verzoek.
Was deze pagina nuttig? Laat ons weten hoe goed we u hebben geholpen:

Feedback verzenden over...

Hulp nodig? Ga naar onze ondersteuningspagina.