Quota en limieten

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

In de lijsten hieronder vindt u de huidige snelheids- en quotumlimieten van het systeem.

Querytaken

De volgende limieten zijn van toepassing op querytaken die automatisch worden gemaakt door interactieve query's uit te voeren, en op taken die programmatisch worden ingediend via een aanroep van de API-methode jobs.query en de querytypespecifieke API-methode jobs.insert.

Snelheidslimiet voor gelijktijdige interactieve query's: 100 gelijktijdige query's

Query's met resultaten die uit het querycachegeheugen worden geretourneerd en 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 het salesteam om de limiet te verhogen.

Snelheidslimiet 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.

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

De snelheidslimiet voor gelijktijdige verouderde SQL-query's met UDF's heeft betrekking op zowel interactieve query's als batchquery's. Interactieve query's met UDF's tellen ook mee voor de snelheidslimiet voor gelijktijdige interactieve query's. Deze limiet geldt niet voor standaard 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: 1000 updates per tabel per dag

Voor bestemmingstabellen in een querytaak geldt een limiet van 1000 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: 6 uur

Deze limiet kan niet worden gewijzigd.

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 gecomprimeerd¹

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

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

Maximale rijgrootte: 100 MB²

²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

Het standaardaantal slots voor on demand-query's wordt gedeeld door alle query's in één project. Over het algemeen geldt dat als u minder dan 100 GB aan query's tegelijk verwerkt, u waarschijnlijk niet alle 2000 slots gebruikt.

Bekijk BigQuery controleren met Stackdriver om te zien hoeveel slots u gebruikt. Als u meer dan 2000 slots nodig heeft, kunt u contact opnemen met uw salesmedewerker om te bespreken of flatrate-prijzen aansluiten bij uw behoeften.

Maximum aantal gelijktijdige query's tegen 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.

Laadtaken

De volgende limieten zijn van toepassing op taken die automatisch worden gemaakt door gegevens te laden via de opdrachtregeltool, de GCP-console of de klassieke web-UI van BigQuery. De limieten zijn ook van toepassing op laadtaken die programmatisch worden ingediend met de laadtypespecifieke API-methode jobs.insert.

De volgende limieten zijn van toepassing wanneer u gegevens laadt in BigQuery.

Laadtaken per tabel per dag: 1000 (inclusief mislukte laadtaken)
Laadtaken per project per dag: 100.000 (inclusief mislukte laadtaken)

De limiet van 1000 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 bestandsgroottes:

Bestandstype	Gecomprimeerd	Niet-gecomprimeerd
csv	4 GB	5 TB
json	4 GB	5 TB
Avro	Gecomprimeerde Avro-bestanden worden niet ondersteund, maar gecomprimeerde gegevensblokken wel. BigQuery ondersteunt de codecs DEFLATE en Snappy.	5 TB (1 MB voor de bestandsheader)

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 uitvoeren 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.

Ga naar 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, de console of de klassieke web-UI van BigQuery. De limieten zijn ook van toepassing op kopieertaken die programmatisch 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 limieten zijn van toepassing op taken die automatisch worden gemaakt door gegevens te exporteren via de opdrachtregeltool, de console of de klassieke web-UI van BigQuery. De limieten zijn ook van toepassing op exporttaken die programmatisch worden ingediend met de laadtypespecifieke API-methode jobs.insert.

Exports per dag: 100.000 exports per project en maximaal 10 TB per dag (de gegevenslimiet van 10 TB is cumulatief voor alle exports)

Als u per dag meer dan 10 TB aan gegevens wilt exporteren, gebruikt u de BigQuery Storage API.

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

Datasetlimieten

De volgende limieten zijn van toepassing op 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 voor datasets worden weergegeven.
Aantal tabellen per dataset: onbeperkt

Als u 50.000 tabellen of meer in een dataset heeft, duurt het opsommen ervan langer. De prestaties van het opsommen nemen af wanneer u een API-aanroep of de klassieke web-UI van BigQuery gebruikt. De web-UI van BigQuery in de GCP-console biedt u op dit moment de mogelijkheid om slechts 50.000 tabellen per dataset weer te geven. 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 datasetmetadata omvat alle updatebewerkingen voor metadata die worden uitgevoerd via de console, de klassieke web-UI van BigQuery, de opdrachtregeltool bq of 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 zijn van toepassing op BigQuery-tabellen.

Alle tabellen

Maximum lengte van een kolombeschrijving: 16.384 tekens

Wanneer u een beschrijving toevoegt aan een kolom, mag de tekst maximaal 16.384 tekens bevatten.

Standaardtabellen

Maximum aantal tabelbewerkingen per dag: 1000

U mag maximaal 1000 bewerkingen per tabel per dag uitvoeren, inclusief het toevoegen en overschrijven van gegevens in een tabel en het gebruik van een DML-INSERT-instructie om gegevens naar een tabel te schrijven.

Het maximum aantal tabelbewerkingen omvat de gecombineerde totale aantallen van alle laadtaken, kopieertaken en querytaken waarbij gegevens worden toegevoegd aan of overschreven in een bestemmingstabel, of waarbij een INSERT-instructie in DML wordt gebruikt om gegevens naar een tabel te schrijven.

Als u bijvoorbeeld 500 kopieertaken uitvoert die gegevens toevoegen aan mytable en 500 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 tabelmetadata omvat alle updatebewerkingen voor metadata die worden uitgevoerd via de GCP-console, de klassieke web-UI van BigQuery, de opdrachtregeltool bq, de clientbibliotheken of de API-methoden tables.insert, tables.patch of tables.update. De limiet geldt ook voor taakuitvoer.

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 één taak kan worden bewerkt: 2000

Een taakbewerking (voor query's of laden) kan op maximaal 2000 partities betrekking hebben. Elke query- of laadtaak op meer dan 2000 partities wordt afgekeurd door BigQuery.

Maximum aantal partitiebewerkingen per dag per tabel: 5000

U mag maximaal 5000 partitiebewerkingen per dag voor een gepartitioneerde tabel uitvoeren. 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.

Eén taak kan op meer dan één 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. 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

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

Wanneer 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 één rij: ongeveer 5 MB of minder
Snelheidslimiet voor gelijktijdige verouderde SQL-query's met door de gebruiker gedefinieerde functies (user-defined functions, UDF): 6 gelijktijdige 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 plus-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 UDF: 5 per 10 seconden Na het maken kunt u elke functie maximaal vijf keer per tien 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
Bitwise-bewerkingen in JavaScript verwerken alleen de belangrijkste 32 bits

Data Manipulation Language-instructies

De volgende limieten gelden voor Data Manipulation Language-instructies (DML-instructies).

Maximum aantal gecombineerde UPDATE-, DELETE- en MERGE-instructies per dag per tabel: 1000

Een MERGE-instructie telt als één DML-instructie, zelfs als deze meerdere INSERT-, UPDATE- en DELETE-clausules bevat.

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:

Deze quota zijn momenteel alleen van toepassing op de multiregionale locatie US. U moet het aanmeldformulier voor de BigQuery Streaming V2-bèta invullen om deze quota te gebruiken.

Maximum aantal rijen per seconde: 1 miljoen

Als u het veld insertId niet invult voor elke ingevoegde rij, geldt er een limiet van 1 miljoen rijen per seconde per project. Dit quotum is cumulatief. U kunt dit volledige quotum voor één tabel gebruiken, maar u kunt het ook gebruiken voor gegevensstreaming naar meerdere tabellen in een project.

Overschrijding van dit aantal leidt tot quotaExceeded-fouten.
Maximum aantal bytes per seconde: 1 GB

Als u het veld insertId niet invult voor elke ingevoegde rij, 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:

Maximum aantal rijen per seconde: 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. Dit quotum is cumulatief. U kunt dit volledige quotum voor één tabel gebruiken, maar u kunt het ook gebruiken voor gegevensstreaming naar meerdere tabellen in een project.

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: 1 MB

Overschrijding van deze waarde leidt tot invalid-fouten.
Groottelimiet HTTP-verzoek: 10 MB

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.

Als u hogere streamingquota voor uw project nodig heeft, kunt u een verzoek indienen via de Google Cloud Platform Console. U kunt een eigen quotum instellen voor het verwerken van gegevens in stappen van 50.000 rijen. U ontvangt meestal binnen twee tot drie 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. 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 tot 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 wordt geretourneerd aan tabledata.list: 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:

Maximum aantal verzoeken per seconde per project: 10 : Als u tables.insert aanroept, kunt u maximaal 10 verzoeken per seconde per project indienen. Deze limiet omvat instructies waarbij tabellen worden gemaakt, zoals de DDL-instructie CREATE TABLE, en query's waarbij resultaten worden geschreven naar bestemmingstabellen.

`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.

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, in overeenstemming met de achterliggende intentie om gedrag op gebied van snelheidslimieten te sturen. Tussentijds vernieuwen wordt ook gedaan om lange onderbrekingen te voorkomen wanneer 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.