Quota en limieten

In de lijsten hieronder vindt u de huidige limieten van BigQuery voor aantallen en quota.

BigQuery hanteert een beperking voor het maximale aantal inkomende verzoeken en legt per project passende quota op. Het specifieke beleid is afhankelijk van de beschikbaarheid van resources, het gebruikersprofiel, de gebruiksgeschiedenis en andere factoren, en kan zonder voorafgaande kennisgeving worden gewijzigd.

Querytaken

De volgende limieten zijn van toepassing op querytaken die automatisch worden gemaakt door interactieve query's uit te voeren, en op taken die programmatic worden ingediend via een methodeaanroep jobs.query en de querytype methodeaanroep jobs.insert.

Query's met resultaten die uit het querycachegeheugen worden geretourneerd, tellen mee voor deze limiet zolang BigQuery nodig heeft om te bepalen of het resultaat aanwezig is in het cachegeheugen. Proefquery's tellen niet mee voor deze limiet. U kunt een proefquery opgeven met de vlag --dry_run of door de property dryRun in te stellen in een querytaak.

Deze limiet wordt toegepast op projectniveau. Neem contact op met support of met sales om de limiet te verhogen.

  • Limiet voor gelijktijdige interactieve query's voor externe gegevensbronnen van Cloud Bigtable: 4 gelijktijdige query's

U kunt maximaal 4 query's tegelijk uitvoeren voor een externe gegevensbron van Cloud Bigtable.

  • Limiet voor het aantal gelijktijdige verouderde SQL-query's met door de gebruiker gedefinieerde functies (user-defined functions, UDF's): 6 gelijktijdige query's

De limiet voor het aantal gelijktijdige verouderde SQL-query's met UDF's geldt voor zowel interactieve als batchquery's. Interactieve query's met UDF's tellen ook mee voor de limiet voor het aantal gelijktijdige interactieve query's. Deze limiet geldt niet voor standaard SQL-query's.

  • Federatieve query's uitvoeren in meerdere regio's — 1 TB per project per dag

Als de BigQuery-query op een andere locatie wordt verwerkt dan de Cloud SQL-instantie, is dit een query in meerdere regio's. U kunt per project per dag maximaal 1 TB aan query's in meerdere regio's uitvoeren. Zie Federatieve Cloud SQL-query's.

  • Dagelijkse limiet voor de grootte van query's: standaard onbeperkt

U kunt eigen quota gebruiken om limieten op te geven voor de hoeveelheid gegevens waar gebruikers query's voor kunnen uitvoeren.

  • Dagelijkse updatelimiet voor bestemmingstabellen: 1500 updates per tabel per dag

Voor bestemmingstabellen in een querytaak geldt een limiet van 1500 updates per tabel per dag. Updates van bestemmingstabellen omvatten toevoeg- en overschrijfbewerkingen die door een query vanuit de console, de klassieke web-UI van BigQuery of de opdrachtregeltool bq worden uitgevoerd, of via een aanroep van de API-methode jobs.query en de querytypespecifieke API-methode jobs.insert.

  • Tijdslimiet voor uitvoering van query/script: 6 uur

Deze limiet kan niet worden gewijzigd. In sommige gevallen kan opnieuw worden geprobeerd om een query uit te voeren. Als dit gebeurt, kan nog eens 6 uur worden geprobeerd de betreffende query uit te voeren. Een query kan tot 3 keer opnieuw worden geprobeerd. Hierdoor kan de totale uitvoertijd boven de 6 uur uitkomen.

  • Maximum aantal tabellen dat een query kan raadplegen: 1000

  • Maximum lengte voor onopgeloste query's voor verouderde SQL: 256 KB

  • Maximum lengte voor onopgeloste query's voor standaard SQL: 1 MB

  • Maximum lengte voor opgeloste query's voor verouderde en standaard SQL: 12 MB

De limiet voor de lengte van opgeloste query's omvat de lengtes van alle weergaven en jokertabellen die door de query worden geraadpleegd.

  • Maximum aantal standaard SQL-queryparameters: 10.000

  • Maximale reactiegrootte: 10 GB gecomprimeerd1

1 Grootten zijn afhankelijk van de compressieverhoudingen voor de gegevens. De daadwerkelijke reactiegrootte kan veel groter zijn dan 10 GB.

De maximum reactiegrootte is onbeperkt als u grote queryresultaten naar een bestemmingstabel schrijft.

  • Maximale rijgrootte: 100 MB2

2 De maximale rijgrootte is bij benadering, omdat de limiet wordt gebaseerd op de interne weergave van rijgegevens. De limiet voor de maximale rijgrootte wordt gehandhaafd in bepaalde fasen van de uitvoering van querytaken.

  • Maximum aantal kolommen in een tabel, queryresultaat of weergavedefinitie: 10.000

  • Maximum aantal gelijktijdige slots per project voor on-demand prijzen: 2000

BigQuery-slots worden gedeeld door alle query's in 1 project. BigQuery overschrijdt mogelijk deze limiet om uw query's sneller uit te voeren.

Bekijk BigQuery controleren met Cloud Monitoring om te zien hoeveel slots u gebruikt.

  • Maximaal aantal gelijktijdige query's voor een externe gegevensbron van Cloud Bigtable: 4

Bekijk de UDF-limieten voor informatie over limieten die gelden voor door de gebruiker gedefinieerde functies in SQL-query's.

  • Geplande query's

Hoewel geplande query's gebruikmaken van functies van de BigQuery Data Transfer Service, zijn het geen overdrachten en vallen ze niet onder het quotum voor laadtaken. Geplande query's vallen onder dezelfde BigQuery-quota en -limieten als handmatige query's.

Laadtaken

De volgende limieten gelden voor taken die automatisch worden gemaakt door gegevens te laden via de opdrachtregeltool, Cloud Console of de klassieke web-UI van BigQuery. De limieten gelden ook voor laadtaken die programmatic worden ingediend met de laadtypespecifieke API-methode jobs.insert.

De volgende limieten gelden als u gegevens laadt in BigQuery.

  • Laadtaken per tabel per dag: 1500 (inclusief mislukte laadtaken)
  • Laadtaken per project per dag: 100.000 (inclusief mislukte laadtaken)
    • De limiet van 1500 laadtaken per tabel per dag kan niet worden verhoogd.
  • Limieten voor rij- en celgrootte:
    Gegevensindeling Max. limiet
    csv 100 MB (rij- en celgrootte)
    json 100 MB (rijgrootte)
  • Maximum aantal kolommen per tabel: 10.000
  • Maximale bestandsgrootten:
    Bestandstype Gecomprimeerd Niet-gecomprimeerd
    csv 4 GB 5 TB
    json 4 GB 5 TB
  • Maximum grootte per laadtaak: 15 TB voor alle invoerbestanden voor csv, json, Avro, Parquet en ORC
  • Maximum aantal bron-URI's in een taakconfiguratie: 10.000 URI's
  • Maximum aantal bestanden per laadtaak: 10 miljoen bestanden in totaal, inclusief alle bestanden die overeenkomen met alle jokerteken-URI's
  • Tijdslimiet voor uitvoering van laadtaken: 6 uur
  • Met uitzondering van datasets in de VS moet u gegevens laden vanuit een Cloud Storage-bucket in dezelfde regio als de locatie van de dataset (dit kan een bucket met meerdere regio's zijn of een regionale bucket die zich in dezelfde regio als de dataset bevindt). Voor datasets in de VS geldt dat u gegevens uit alle regio's hierin kunt laden.

Zie Introductie tot gegevens laden in BigQuery voor meer informatie.

Kopieertaken

De volgende limieten gelden voor het kopiëren van tabellen in BigQuery. De limieten zijn van toepassing op taken die automatisch worden gemaakt door gegevens te kopiëren via de opdrachtregeltool bq, de Cloud Console of de klassieke web-UI van BigQuery. De limieten gelden ook voor kopieertaken die programmatic worden ingediend met de kopieertypespecifieke API-methode jobs.insert.

  • Kopieertaken per bestemmingstabel per dag: 1000 (inclusief mislukte kopieertaken)
  • Kopieertaken per project per dag: 100.000 (inclusief mislukte kopieertaken)

Exporttaken

De volgende limieten gelden voor taken die gegevens exporteren uit BigQuery. De volgende limieten zijn van toepassing op taken die automatisch worden gemaakt door gegevens te exporteren via de opdrachtregeltool bq, de Cloud Console of de klassieke web-UI van BigQuery. De limieten gelden ook voor exporttaken die programmatic worden ingediend met de laadtypespecifieke API-methode jobs.insert.

  • Exports per dag: 100.000 exports per project en maximaal 50 TB per dag (de gegevenslimiet van 50 TB is een optelsom van alle exports)

    • Gebruik de BigQuery Storage API als u meer dan 50 TB aan gegevens per dag wilt exporteren.

  • Jokerteken-URI's: 500 jokerteken-URI's per export

Datasetlimieten

De volgende limieten gelden voor datasets:

  • Aantal datasets per project: onbeperkt
    Er geldt geen quotum voor het aantal datasets per project, maar als u duizenden datasets in een project heeft, nemen de prestaties van de klassieke web-UI af en duurt het langer voordat datasets worden weergegeven.
  • Aantal tabellen per dataset: onbeperkt
    Als u 50.000 tabellen of meer in een dataset heeft, duurt het weergeven ervan langer. De prestaties van de weergave nemen af als u een API-aanroep of de klassieke web-UI van BigQuery gebruikt. De web-UI van BigQuery in de Google Cloud Console kan op dit moment maar 50.000 tabellen per dataset weergeven. Als u de prestaties van de klassieke web-UI van BigQuery wilt verbeteren, kunt u met de parameter ?minimal het aantal weergegeven tabellen beperken tot 30.000 tabellen per project. U voegt de parameter in de volgende indeling toe aan de URL van de klassieke web-UI van BigQuery: https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal.
  • Maximum aantal gemachtigde weergaven in een toegangscontrolelijst van een dataset: 2500
    U kunt een gemachtigde weergave maken om de toegang tot uw brongegevens te beperken. Een gemachtigde weergave wordt gemaakt met een SQL-query die kolommen uitsluit die u niet zichtbaar wilt maken voor gebruikers als ze een query op de weergave uitvoeren. U kunt tot 2500 gemachtigde weergaven toevoegen aan de toegangscontrolelijst van een dataset.
  • Maximum snelheid van de updatebewerkingen voor de metadata van een dataset: 5 bewerkingen per 10 seconden per dataset
    De updatelimiet voor metadata van een dataset geldt voor alle updatebewerkingen voor metadata die worden uitgevoerd via de console, de klassieke web-UI van BigQuery, de opdrachtregeltool bq of via een aanroep van de API-methoden datasets.insert, datasets.patch of datasets.update.
  • Maximum lengte van een datasetbeschrijving: 16.384 tekens
    Als u een beschrijving toevoegt aan een dataset, mag de tekst maximaal 16.384 tekens bevatten.

Tabellimieten

De volgende limieten gelden voor BigQuery-tabellen.

Alle tabellen

  • Maximum lengte van een kolombeschrijving: 1024 tekens

Als u een beschrijving toevoegt aan een kolom, mag de tekst maximaal 1024 tekens bevatten.

Standaardtabellen

  • Maximum aantal tabelbewerkingen per dag: 1500

U mag maximaal 1500 bewerkingen per tabel per dag uitvoeren. Bij dit aantal is het toevoegen van gegevens in een tabel of het afbreken van een tabel inbegrepen.

Het maximum aantal tabelbewerkingen is het gecombineerde totaal van alle laadtaken, kopieertaken en querytaken waarbij gegevens worden toegevoegd aan of overschreven in een bestemmingstabel, of waarbij een INSERT-, UPDATE-, DELETE- of MERGE-instructie in DML wordt gebruikt om gegevens naar een tabel te schrijven. DML-instructies tellen mee voor dit quotum, maar worden er niet door beperkt. Met andere woorden: het aantal dagelijkse bewerkingen dat meetelt voor het quotum omvat DML-instructies, maar er kunnen vanwege deze limiet geen problemen met DML-instructies ontstaan.

Als u bijvoorbeeld 500 kopieertaken uitvoert die gegevens toevoegen aan mytable en 1000 querytaken uitvoert die gegevens toevoegen aan mytable, bereikt u het quotum.

  • Maximum snelheid van de updatebewerkingen voor de metadata van een tabel: 5 bewerkingen per 10 seconden per tabel

De updatelimiet voor metadata van tabellen geldt voor alle updatebewerkingen voor metadata die worden uitgevoerd via de Cloud Console, de klassieke web-UI van BigQuery, de opdrachtregeltool bq, de clientbibliotheken, via een aanroep van de API-methoden tables.insert, tables.patch of tables.update, of door de DDL-instructies ALTER TABLE uit te voeren. De limiet geldt ook voor de uitvoer van taken.

  • Maximum aantal kolommen in een tabel, queryresultaat of weergavedefinitie: 10.000

Gepartitioneerde tabellen

  • Maximum aantal partities per gepartitioneerde tabel: 4000

  • Maximum aantal partities dat met 1 taak kan worden bewerkt: 4000

Elke taakbewerking (query's of laden) kan op maximaal 4000 partities plaatsvinden. Elke query- of laadtaak op meer dan 4000 partities wordt afgekeurd door BigQuery.

  • Maximum aantal partitiebewerkingen per op basis van verwerkingstijd gepartitioneerde tabel: 5000
  • Maximum aantal partitiebewerkingen per op basis van kolommen gepartitioneerde tabel: 30.000

U mag maximaal 5000 partitiebewerkingen per dag uitvoeren voor een op basis van verwerkingstijd gepartitioneerde tabel en 30.000 partitiebewerkingen voor een op basis van kolommen gepartitioneerde tabel. Een partitie kan worden aangepast door een bewerking te gebruiken die gegevens toevoegt aan of overschrijft in de partitie. Bewerkingen die partities aanpassen, zijn onder andere een laadtaak, een query die resultaten schrijft naar een partitie of een DML-instructie (INSERT, DELETE, UPDATE of MERGE) die gegevens in een partitie aanpast.

1 taak kan op meer dan 1 partitie invloed hebben. Een DML-instructie kan bijvoorbeeld gegevens updaten in meerdere partities (voor zowel verwerkingstijd als gepartitioneerde tabellen). Querytaken en laadtaken kunnen ook schrijven naar meerdere partities, maar alleen voor gepartitioneerde tabellen. DML-instructies tellen mee voor dit quotum, maar worden er niet door beperkt. Met andere woorden: het aantal dagelijkse bewerkingen dat meetelt voor het quotum omvat DML-instructies, maar er kunnen vanwege deze limiet geen problemen met DML-instructies ontstaan. BigQuery gebruikt het aantal partities dat wordt beïnvloed door de taak om te bepalen welk deel van het quotum de taak verbruikt. Invoegen via streaming heeft geen invloed op dit quotum.

  • Maximum snelheid van partitiebewerkingen: 50 partitiebewerkingen per 10 seconden

Externe tabellen

De volgende limieten gelden voor tabellen met gegevens die in Parquet-, ORC-, Avro-, csv- of json-indeling zijn opgeslagen in Cloud Storage.

  • Maximum aantal bron-URI's per externe tabel: 10.000 URI's
  • Maximum aantal bestanden per externe tabel: 10 miljoen bestanden in totaal, inclusief alle bestanden die overeenkomen met alle jokerteken-URI's
  • Maximale grootte van de opgeslagen gegevens in Cloud Storage per externe tabel voor alle invoerbestanden: 600 TB

    Deze limiet geldt voor alle bestandsgrootten in Cloud Storage. Dit is niet dezelfde grootte als die wordt gebruikt in de formule voor de berekening van de prijzen voor query's. Voor extern gepartitioneerde tabellen wordt de limiet toegepast nadat de partities zijn opgeschoond.

Limieten bekijken

  • Maximum aantal geneste weergaveniveaus: 16

BigQuery ondersteunt maximaal 16 niveaus voor geneste weergaven. Als er meer dan 16 niveaus zijn, wordt een INVALID_INPUT-fout geretourneerd.

  • Maximale lengte van een standaard SQL-query die wordt gebruikt om een weergave te definiëren: 256.000 tekens

Als u een weergave maakt, kan de tekst van de standaard SQL-query maximaal 256.000 tekens bevatten.

  • Maximum aantal gemachtigde weergaven in een toegangscontrolelijst van een dataset: 2500

U kunt een gemachtigde weergave maken om de toegang tot uw brongegevens te beperken. Een gemachtigde weergave wordt gemaakt met een SQL-query die kolommen uitsluit die u niet zichtbaar wilt maken voor gebruikers als ze een query op de weergave uitvoeren. U kunt tot 2500 gemachtigde weergaven toevoegen aan de toegangscontrolelijst van een dataset.

UDF-limieten

De volgende limieten gelden voor tijdelijke en persistente door de gebruiker gedefinieerde functies in SQL-query's.

  • Hoeveelheid gegevens in de uitvoer van uw JavaScript-UDF bij de verwerking van 1 rij: ongeveer 5 MB of minder
  • Limiet voor het aantal gelijktijdige verouderde SQL-query's met door de gebruiker gedefinieerde functies (user-defined functions, UDF): 6 gelijktijdige query's

    • De limiet voor het aantal gelijktijdige verouderde SQL-query's met UDF's geldt voor zowel interactieve als batchquery's. Interactieve query's met UDF's tellen ook mee voor de limiet voor het aantal gelijktijdige interactieve query's. Deze limiet geldt niet voor standaard SQL-query's.

  • Maximum aantal JavaScript UDF-resources, zoals inline codeblobs of externe bestanden in een querytaak: 50
  • Maximale grootte van elke inline codeblob: 32 KB
  • Maximale grootte van elke externe codebron: 1 MB

De volgende limieten gelden voor persistente door de gebruiker gedefinieerde functies.
  • Maximale lengte van een functienaam: 256 tekens
  • Maximum aantal argumenten: 256
  • Maximale lengte van een argumentnaam: 128 tekens
  • Maximale diepte van een door de gebruiker gedefinieerde functieverwijzingsketen: 16
  • Maximale diepte van een argument of uitvoer van het type STRUCT: 15
  • Maximum aantal velden in een argument of uitvoer van het type STRUCT per UDF: 1024
  • Maximum aantal unieke UDF en tabelverwijzingen per query: 1000 Na volledige uitbreiding kan elke UDF naar maximaal 1000 gecombineerde unieke tabellen en UDF's verwijzen.
  • Maximum aantal JavaScript-bibliotheken in de instructie CREATE FUNCTION: 50
  • Maximale lengte van opgenomen JavaScript-bibliotheekpaden: 5000 tekens
  • Maximale updatesnelheid per UDF: 5 per 10 seconden Na het maken kunt u elke functie maximaal 5 keer per 10 seconden updaten.
  • Elke inline codeblob is beperkt tot een maximum grootte van 32 KB
  • Elke JavaScript-codebron is beperkt tot een maximum grootte van 1 MB

Data Manipulation Language-instructies

BigQuery DML-instructies hebben geen quotumlimieten.

DML-instructies tellen mee voor het maximum aantal tabelbewerkingen per dag en partitiebewerkingen per dag. Vanwege deze limiet kunnen er geen problemen met DML-instructies ontstaan.

Daarnaast vallen DML-instructies onder de maximum snelheid van de updatebewerkingen voor de metadata van een tabel. Als u deze limiet overschrijdt, kunt u proberen de bewerking opnieuw uit te voeren met exponentiële back-off tussen de pogingen.

Invoegen via streaming

De volgende limieten zijn van toepassing op het streamen van gegevens naar BigQuery.

Als u het veld insertId niet invult wanneer u rijen invoegt, gelden de volgende quota. Zie Best mogelijke deduplicatie uitschakelen voor meer informatie. Dit is de aanbevolen manier om BigQuery te gebruiken. Zo krijgt u hogere quotumlimieten voor streamverwerking.

  • Maximum aantal bytes per seconde: 1 GB. Als u het veld insertId niet voor elke ingevoegde rij invult, geldt er een limiet van 1 GB per seconde per project. Deze limiet wordt toegepast op projectniveau. De limiet geldt niet voor afzonderlijke tabellen. Overschrijding van dit aantal leidt tot quotaExceeded-fouten.

Als u het veld insertId invult wanneer u rijen invoegt, gelden de volgende quota.

  • Maximaal aantal rijen per seconde per project in us en eu (meerdere regio's): 500.000
    Als u het veld insertId invult voor elke ingevoegde rij, geldt er een limiet van 500.000 rijen per seconde per project in us en eu (meerdere regio's). Dit quotum is een optelsom binnen elk gebied met meerdere regio's. Met andere woorden: voor de som van het aantal rijen dat per seconde wordt gestreamd naar alle tabellen, geldt voor elk project binnen een gebied met meerdere regio's een limiet van 500.000. Voor elke tabel geldt daarnaast een limiet van 100.000 rijen per seconde.

    Overschrijding van de limiet per project of tabel leidt tot quotaExceeded-fouten.
  • Maximaal aantal rijen per seconde per project op alle andere locaties: 100.000
    Als u het veld insertId invult voor elke ingevoegde rij, geldt er een limiet van 100.000 rijen per seconde per project of tabel, op alle locaties behalve us en eu (meerdere regio's). Dit quotum is een optelsom binnen elke regio. Met andere woorden: voor de som van het aantal rijen dat per seconde wordt gestreamd naar alle tabellen, geldt voor elk project binnen een regio een limiet van 100.000.

    Overschrijding van dit aantal leidt tot quotaExceeded-fouten.
  • Maximaal aantal rijen per seconde per tabel: 100.000
    Als u het veld insertId invult voor elke ingevoegde rij, geldt er een limiet van 100.000 rijen per seconde per tabel.

    Overschrijding van dit aantal leidt tot quotaExceeded-fouten.
  • Maximum aantal bytes per seconde: 100 MB
    Als u het veld insertId invult voor elke ingevoegde rij, geldt er een limiet van 100 MB per seconde per tabel.

    Overschrijding van dit aantal leidt tot quotaExceeded-fouten.

De volgende aanvullende streamingquota zijn van toepassing, ongeacht of u het veld insertId invult:

  • Maximum rijgrootte: 5 MB
    Overschrijding van deze waarde leidt tot invalid-fouten.
  • Groottelimiet HTTP-verzoek: 10 MB (zie opmerking)
    Overschrijding van deze waarde leidt tot invalid-fouten.
  • Maximum aantal rijen per verzoek: 10.000
    We adviseren u om maximaal 500 rijen te gebruiken. Met batching kunt u de prestaties en verwerkingssnelheid tot op zekere hoogte verbeteren, maar dit gaat ten koste van de wachttijd per verzoek. Als er te weinig rijen per verzoek zijn, is de overhead per verzoek te hoog en is de verwerking mogelijk niet efficiënt. Als er te veel rijen per verzoek zijn, kan de verwerkingssnelheid afnemen.

    We adviseren u om maximaal 500 rijen per verzoek te gebruiken, maar door te experimenteren met representatieve gegevens (qua schema en gegevensgrootte) kunt u de ideale batchgrootte bepalen.
  • Lengte van het veld insertId: 128
    Overschrijding van deze waarde leidt tot invalid-fouten.

Als u een hoger streamingquotum voor uw project nodig heeft, kunt u best mogelijke deduplicatie uitschakelen. Als u een hoger quotum dan de limieten nodig heeft, kunt u een verzoek indienen via de Google Cloud Console. U ontvangt meestal binnen 2 tot 3 werkdagen een reactie.

API-verzoeken

Alle API-verzoeken

De volgende limieten zijn van toepassing op alle BigQuery-API-verzoeken:

  • API-verzoeken per seconde per gebruiker: 100
    Als u meer dan 100 verzoeken per seconde indient, kan er een vertraging optreden. Deze limiet is niet van toepassing op invoegen via streaming.
  • Gelijktijdige API-verzoeken, per gebruiker: 300
    Als u meer dan 300 gelijktijdige verzoeken per gebruiker indient, kan er een vertraging optreden. Deze limiet is niet van toepassing op invoegen via streaming.

tabledata.list-verzoeken

De methode tabledata.list haalt tabelgegevens op uit een opgegeven verzameling rijen. Andere API's zoals jobs.getQueryResults en het ophalen van resultaten van jobs.query en jobs.insert kunnen de quota van deze API ook verbruiken. De volgende limieten zijn van toepassing op tabledata.list-verzoeken:

  • Maximum aantal tabledata.list-query's per project: 500/seconde
    Als u tabledata.list aanroept, kunt u maximaal 500 verzoeken per seconde per project indienen.
  • Maximum aantal bytes per seconde per project dat door aanroepen wordt geretourneerd aan tabledata.list: 60 MB/seconde
    Als u tabledata.list aanroept, kunt u maximaal 60 MB tabelrijgegevens per seconde per project retourneren. De limiet is van toepassing op het project dat de tabel met de gelezen gegevens bevat.
  • Maximum aantal rijen per seconde per project dat door aanroepen aan tabledata.list wordt geretourneerd: 150.000/seconde
    Als u tabledata.list aanroept, kunt u maximaal 150.000 tabelrijen per seconde per project retourneren. De limiet is van toepassing op het project dat de tabel met de gelezen gegevens bevat.

tables.insert-verzoeken

De methode tables.insert maakt een nieuwe, lege tabel in een dataset. De volgende limieten zijn van toepassing op tables.insert-verzoeken:

projects.list-verzoeken

De methode projects.list geeft alle projecten weer waartoe u toegang heeft. De volgende limieten zijn van toepassing op projects.list-verzoeken:

  • Maximum aantal verzoeken per seconde per project: 2. Als u projects.list aanroept, kunt u maximaal 2 verzoeken per seconde per project indienen.

jobs.get-verzoeken

De methode jobs.get retourneert informatie over een specifieke taak. De volgende limieten zijn van toepassing op jobs.get-verzoeken:

  • Maximum aantal verzoeken per seconde per project: 1000. Als u jobs.get aanroept, kunt u maximaal 1000 verzoeken per seconde per project indienen.

jobs.query-verzoeken

De methode jobs.query voert synchroon een SQL-query uit en retourneert queryresultaten als de query zonder gespecificeerde time-out wordt voltooid.

  • Maximale reactiegrootte: 10 MB. Standaard geldt er geen maximum aantal gegevensrijen dat per resultatenpagina wordt geretourneerd. Er geldt wel een maximale reactiegrootte van 10 MB. U kunt het aantal te retourneren rijen wijzigen met de parameter maxResults.

IAM API-verzoeken

De volgende limieten zijn van toepassing als u identiteits- en toegangsbeheerfuncties gebruikt in BigQuery om IAM-beleid op te halen en in te stellen en om IAM-rechten te testen.

  • Voor Google Cloud-projecten geldt een limiet van 25 verzoeken per seconde per gebruiker.

  • Voor Google Cloud-projecten geldt een limiet van 50 verzoeken per seconde.

Als u hogere IAM-quota voor uw project nodig heeft, kunt u een verzoek indienen via de Google Cloud Console. U ontvangt meestal binnen twee tot drie werkdagen een reactie.

BigQuery Storage API-verzoeken

De volgende limieten gelden voor ReadRows-aanroepen via de BigQuery Storage API:

  • ReadRows-aanroepen per minuut: 5000. Als u gegevens leest via de BigQuery Storage API, kunt u maximaal 5000 ReadRows-aanroepen per minuut per gebruiker per project uitvoeren.

De volgende limieten zijn van toepassing op alle overige methodeaanroepen via de BigQuery Storage API:

  • API-aanroepen per minuut: 1000. U kunt maximaal 1000 BigQuery Storage API-aanroepen per minuut per gebruiker per project uitvoeren.

Wanneer worden quota aangevuld?

Dagelijkse quota worden met regelmatige tussenpozen gedurende de dag aangevuld, met de bedoeling de rate limiting te sturen. Er wordt ook tussentijds vernieuwd om lange onderbrekingen te voorkomen als het quotum is opgebruikt. Een hoger quotum wordt in de regel binnen enkele minuten beschikbaar gesteld, in plaats van het quotum één keer per dag aan te vullen.

Foutcodes

Quotum- en limietfouten retourneren een 403- of 400-HTTP-reactiecode. Bekijk Problemen oplossen bij fouten voor een volledige lijst van foutcodes en de stappen om problemen op te lossen.

Quotumgebruik beperken

Zie Gebruik beperken voor meer informatie over hoe u het gebruik van een bepaalde resource kunt beperken tot de limiet die is gespecificeerd door Google.