Informationen zu Slots

Ein BigQuery-Slot ist eine virtuelle Recheneinheit, die von BigQuery zum Ausführen von SQL-Abfragen, Python-Code oder anderen Jobtypen verwendet wird. Während der Ausführung einer Abfrage ermittelt BigQuery automatisch, wie viele Slots von der Abfrage verwendet werden. Die Anzahl der verwendeten Slots hängt von der Menge der verarbeiteten Daten, der Komplexität der Abfrage und der Anzahl der verfügbaren Slots ab. Im Allgemeinen können Sie durch den Zugriff auf mehr Slots mehr gleichzeitige Abfragen ausführen und komplexe Abfragen schneller ausführen. Sie können die Anzahl der Slots, die von BigQuery zum Ausführen von Abfragen verwendet werden, nicht manuell ändern.

On-Demand- und kapazitätsbasierte Preise

Alle Abfragen verwenden Slots. Sie haben jedoch zwei Optionen für die Abrechnung der Nutzung: das On-Demand-Preismodell oder das kapazitätsbasierte Preismodell.

Standardmäßig werden Ihnen die Kosten gemäß dem On-Demand-Modell in Rechnung gestellt. Bei diesem Modell wird Ihnen die Datenmenge in Rechnung gestellt, die bei jeder Abfrage verarbeitet wird (gemessen in TiB). Projekte, die das On-Demand-Modell verwenden, unterliegen einem Limit für die maximale Anzahl gleichzeitiger Slots für On-Demand-Preise mit vorübergehender Burst-Funktion. Für die meisten Nutzer des On-Demand-Modells ist dieses Slotkapazitätslimit mehr als ausreichend. Abhängig von Ihrer Arbeitslast kann der Zugriff auf mehr Slots jedoch die Abfrageleistung verbessern. Informationen zum Prüfen der Slot-Nutzung Ihres Kontos finden Sie unter Zustand, Ressourcennutzung und Jobs überwachen.

Beim kapazitätsbasierten Modell bezahlen Sie für die Slotkapazität, die Ihren Abfragen im Laufe der Zeit zugewiesen wird. Dieses Modell ermöglicht Ihnen die explizite Kontrolle über die gesamte Slot-Kapazität. Sie wählen die Anzahl der zu verwendenden Slots explizit über eine Reservierung aus. Sie können die Anzahl der Slots in einer Reservierung als Baseline-Betrag angeben, der immer zugewiesen wird, oder als automatisch skalierter Betrag, der bei Bedarf zugewiesen wird. Reservierungen mit Autoscaling-Slots skalieren ihre Kapazität entsprechend Ihren Arbeitslastanforderungen. BigQuery weist Slots zu, wenn sich Arbeitslasten ändern. So können Sie die Anzahl der Slots in einer Reservierung basierend auf der Leistung oder der kritischen Natur der Arbeitslast konfigurieren, die die Reservierung verwendet.

Unerwartete On‑Demand-Kosten vermeiden

Damit nicht zugewiesene oder neu erstellte Projekte nicht standardmäßig On-Demand-Preise verwenden, verwalten Sie Ihre BigQuery-Reservierungen mithilfe derGoogle Cloud -Ressourcenhierarchie mit den folgenden Best Practices:

• Auf Ordner- oder Organisationsebene zuweisen: Anstatt eine Einrichtung für jedes Projekt vorzunehmen, können Sie eine Reservierungszuweisung auf Ordner- oder Organisationsebene erstellen. Dadurch wird sichergestellt, dass alle vorhandenen und zukünftigen Projekte innerhalb dieser Hierarchie die Reservierung automatisch übernehmen und die Slot-Kapazität der Reservierung verwenden.
• Standardverhalten berücksichtigen: Ohne explizite oder übernommene Zuweisung wendet BigQuery automatisch das On-Demand-Preismodell an.
• Überschreiben für Ausnahmen: Wenn für bestimmte Projekte On-Demand-Preise verwendet werden müssen, können Sie die übernommene Zuweisung überschreiben, indem Sie diese Projekte explizit der Reservierung Keine zuweisen.

Weitere Informationen zur Zuweisungspriorität finden Sie unter Reservierungszuweisungen.

Abfrage mit Slots ausführen

Bei der Ausführung eines Abfragejobs in BigQuery wird die SQL-Anweisung in einen Ausführungsplan umgewandelt, der aus einer Reihe von Abfragephasen besteht. Phasen bestehen wiederum aus einer Reihe von Ausführungsschritten. BigQuery nutzt zum Ausführen von Abfragen eine verteilte parallele Architektur. In den Phasen werden die Arbeitseinheiten modelliert, die parallel ausgeführt werden können. Daten werden zwischen den Phasen mithilfe einer verteilten Shuffle-Architektur übertragen, die in diesem Google Cloud -Blogpost ausführlicher erläutert wird.

Das Ausführen von Abfragen erfolgt in BigQuery dynamisch. Ein Abfrageplan kann während der Verarbeitung der Abfrage geändert werden. Die Arbeitsverteilung kann für die Datenverteilung optimiert werden, wenn Phasen hinzugefügt werden. Darüber hinaus kann sich die Kapazität für die Ausführung einer Abfrage ändern, wenn andere Abfragen gestartet oder beendet werden oder wenn das Autoscaling einer Reservierung Slots hinzufügt.

BigQuery kann mehrere Phasen gleichzeitig ausführen, eine spekulative Ausführung nutzen, um eine Abfrage zu beschleunigen, und eine Phase dynamisch neu partitionieren, um eine optimale Parallelisierung zu erzielen.

Slotressourcen

Wenn eine Abfrage mehr Slots anfordert, als verfügbar sind, stellt BigQuery die einzelnen Arbeitseinheiten in eine Warteschlange und wartet, bis Slots verfügbar werden. Während der Ausführung der Abfragen werden diese zurückgestellten Arbeitseinheiten dynamisch für die Ausführung ausgewählt.

BigQuery kann für eine bestimmte Phase einer Abfrage eine beliebige Anzahl an Slots anfordern. Die Anzahl der angeforderten Slots hat nichts mit der Kapazität zu tun, die Sie erwerben, sondern weist eher auf den optimalen Parallelisierungsfaktor hin, den BigQuery für diese Phase ausgewählt hat. Arbeitseinheiten werden in die Warteschlange aufgenommen und ausgeführt, sobald Slots verfügbar werden.

Überschreiten Abfrageanforderungen die verfügbaren Slots, werden Ihnen keine zusätzlichen Slots in Rechnung gestellt und Ihnen wird kein zusätzlicher On-Demand-Preis berechnet. Stattdessen werden Ihre Arbeitseinheiten in die Warteschlange verschoben.

Beispiel:

1. In einer Abfragephase werden 2.000 Slots angefordert, es sind jedoch nur 1.000 verfügbar.
2. BigQuery nutzt alle 1.000 Slots, während die verbleibenden Arbeitseinheiten in der Warteschlange auf die übrigen 1.000 Slots warten.
3. Ist die Arbeit von 100 Slots abgeschlossen, werden diese dynamisch an 100 Arbeitseinheiten von den 1.000 Arbeitseinheiten in der Warteschlange vergeben. 900 Arbeitseinheiten verbleiben in der Warteschlange.
4. Ist danach die Arbeit von 500 weiteren Slots erledigt, werden 500 Arbeitseinheiten dieser 900 Arbeitseinheiten dynamisch aus der Warteschlange genommen. 400 Arbeitseinheiten verbleiben in der Warteschlange.

BigQuery-Slots in der Warteschlange – der Bedarf übersteigt die Verfügbarkeit

Wenn die Arbeitslast mehr Slots erfordert, als für die Reservierung verfügbar sind, kann sich die Joblaufzeit erhöhen, da die Jobs warten müssen, bis Slots verfügbar sind. Dies wird als Slot-Konflikt bezeichnet. Slot-Konflikte können zunehmen, wenn die Arbeitslastanforderung viel größer ist als die für die Reservierung verfügbaren Slots.

Kapazitätspriorisierung

Wenn in einer bestimmten Region eine hohe Nachfrage nach Slotressourcen besteht, wird die Ressourcenkonkurrenz durch Priorisierung der Kapazität verwaltet. Durch diese Priorisierung wird sichergestellt, dass Kunden mit Kapazitätsmodellen der höheren Stufe weniger betroffen sind. Das System priorisiert die Kapazität in der folgenden Reihenfolge:

1. Enterprise Plus- und Enterprise-Versionen: Baselines und zugesicherte Kapazität.
2. Automatisch skalierte Enterprise Plus-Kapazität.
3. Automatisch skalierte Kapazität der Enterprise-Version.
4. Standard-Edition und On-Demand-Kapazität.

Bei Konflikten in einer Region ist es wahrscheinlicher, dass bei Anfragen für die Standard-Edition und On-Demand-Kapazität Zugriffsverzögerungen auftreten, da das System Ressourcen zuerst höherwertigen Versionen zuweist.

Faire Planung in BigQuery

BigQuery weist die Slotkapazität innerhalb einer einzelnen Reservierung mithilfe eines Algorithmus namens faire Planung zu.

Der BigQuery-Planer erzwingt die gleichmäßige Aufteilung von Slots zwischen Projekten mit in Ausführung befindlichen Abfragen innerhalb einer Reservierung und anschließend zwischen Jobs eines bestimmten Projekts. Der Planer sorgt für eine finale Gleichmäßigkeit. Während kurzer Zeit können einige Jobs einen unverhältnismäßig hohen Anteil an Slots erhalten, aber der Planer korrigiert dies schließlich. Das Ziel des Planers besteht darin, ein Gleichgewicht zwischen aggressiven Beenden von laufenden Aufgaben (was zu einer Verschwendung von Slot-Zeit führt) und zu viel Nachsicht (was dazu führt, dass Jobs mit lang andauernden Aufgaben einen unverhältnismäßig hohen Anteil an Slot-Zeit erhalten) zu finden.

Die faire Planung sorgt dafür, dass jede Abfrage jederzeit Zugriff auf alle verfügbaren Slots hat. Die Kapazität wird dynamisch und automatisch zwischen den aktiven Abfragen neu zugewiesen, wenn sich die Kapazitätsanforderungen der Abfragen ändern. Unter den folgenden Bedingungen werden Abfragen abgeschlossen und neue Abfragen zur Ausführung gesendet:

• Wenn eine neue Abfrage gesendet worden ist, wird die Kapazität automatisch neu an die ausgeführten Abfragen zugewiesen. Einzelne Arbeitseinheiten können unterbrochen, fortgesetzt und in die Warteschlange aufgenommen werden, je nachdem, wie viel Kapazität für die einzelnen Abfragen zur Verfügung steht.
• Sobald eine Abfrage abgeschlossen worden ist, wird die von dieser Abfrage genutzte Kapazität für alle anderen Abfragen verfügbar.
• Wenn sich die Kapazitätsanforderungen einer Abfrage aufgrund von Änderungen im dynamischen DAG der Abfrage ändern, bewertet BigQuery die Kapazitätsverfügbarkeit für diese und alle anderen Abfragen automatisch neu. Wenn nötig, werden Slots neu zugewiesen oder unterbrochen.

Faire Planung in BigQuery

Je nach Komplexität und Größe einer Abfrage sind möglicherweise nicht alle Slots erforderlich, auf die sie Zugriff hat, oder es sind mehr erforderlich. BigQuery stellt unter Beachtung der fairen Planung dynamisch sicher, dass alle Slots jederzeit voll genutzt werden können.

Wenn ein wichtiger Job durchgängig mehr Slots benötigt, als der Planer ihm bereitstellt, sollten Sie eventuell eine zusätzliche Reservierung mit der erforderlichen Anzahl von Slots erstellen und den Job der Reservierung zuweisen.

Angenommen, Sie haben die folgende Reservierungskonfiguration:

• Reservierung A mit 1.000 Referenz-Slots ohne Autoscaling
• Projekt A und Projekt B, die Ihrer Reservierung zugewiesen sind

Szenario 1: Im Projekt A führen Sie die Abfrage A (eine gleichzeitige Abfrage) aus, die eine hohe Slotnutzung erfordert, und im Projekt B führen Sie 20 gleichzeitige Abfragen aus. Obwohl insgesamt 21 Abfragen die Reservierung A verwenden, sieht die Slot-Verteilung so aus:

• Projekt A erhält 500 Slots und die Abfrage A wird mit 500 Slots ausgeführt.
• Projekt B erhält 500 Slots, die auf die 20 Abfragen aufgeteilt werden.

Szenario 2: In Projekt A führen Sie die Abfrage A (eine gleichzeitige Abfrage) aus, für die 100 Slots erforderlich sind. In Projekt B führen Sie 20 gleichzeitige Abfragen aus. Da für die Abfrage A nicht 50% der Reservierung erforderlich sind, sieht die Slot-Verteilung so aus:

• Projekt A erhält 100 Slots und die Abfrage A wird mit 100 Slots ausgeführt.
• Projekt B erhält 900 Slots, die von den 20 Abfragen gemeinsam genutzt werden.

Betrachten Sie umgekehrt die folgende Reservierungskonfiguration:

• Reservierung B mit 1.000 Referenz-Slots ohne Autoscaling.
• 10 Projekte, die alle der Reservierung B zugewiesen sind.

Angenommen, die 10 Projekte führen Abfragen mit ausreichender Slot-Nachfrage aus. Dann erhält jedes Projekt 1/10 der gesamten Reservierungs-Slots (oder 100 Slots), unabhängig davon, wie viele Abfragen in jedem Projekt ausgeführt werden.

Slotkontingente und -limits

Slot-Kontingente und -Limits schützen BigQuery. Bei den verschiedenen Preismodellen werden unterschiedliche Slot-Kontingenttypen verwendet:

• On-Demand-Preismodell: Für Sie gilt ein Limit für die maximale Anzahl gleichzeitiger Slots für On-Demand-Preise mit vorübergehender Burst-Funktion. Abhängig von Ihren Arbeitslasten kann der Zugriff auf mehr Slots die Abfrageleistung verbessern.

• Kapazitätsbasiertes Preismodell: Reservierungskontingente und -limits definieren die maximale Anzahl von Slots, die Sie allen Reservierungen an einem Standort zuweisen können. Wenn Sie Autoscaling verwenden, darf die Summe Ihrer maximalen Reservierungsgrößen dieses Limit nicht überschreiten. Ihnen werden nur die Reservierungen und Zusicherungen in Rechnung gestellt, nicht die Kontingente. Informationen zum Erhöhen des Slot-Kontingents finden Sie unter Kontingenterhöhung anfordern.

Beachten Sie den Unterschied zwischen zugewiesenen Slots (die sich auf Ihr Kontingent und Ihre Abrechnung auswirken) und genutzten Slots (die aktive Rechenleistung darstellen). Einen detaillierten Vergleich der beiden finden Sie unter Slot-Messwerte.

Informationen zur Anzahl der von Ihnen genutzten Slots finden Sie unter BigQuery-Monitoring.

Inaktive Slots

Das Konzept der inaktiven Slots gilt nur für das kapazitätsbasierte Preismodell und nicht für die automatisch skalierten Slots. Die Slots gelten in zwei Szenarien als „Inaktiv“:

• Slots aus Zusicherungen, die keiner Reservierungsreferenz zugewiesen sind.
• Slots, die einer Reservierungsreferenz zugewiesen sind, aber nicht aktiv von Jobs innerhalb dieser Reservierung verwendet werden.

Um den Wert und die Effizienz Ihrer erworbenen Kapazität zu maximieren, ist BigQuery so konzipiert, dass diese inaktiven Slots automatisch freigegeben werden. Standardmäßig können Abfragen, die in einer Reservierung ausgeführt werden, inaktive Slots aus anderen Reservierungen innerhalb desselben Administrationsprojekts verwenden.

Wenn die Reservierung, die diese Slots „besitzt“, sie für einen Job benötigt, werden sie von BigQuery sofort zurückgefordert. Die Rückgabe ausgeliehener Slots erfolgt nahtlos innerhalb weniger Millisekunden, damit die Arbeitslast der Reservierung, zu der die Slots gehören, nicht beeinträchtigt wird. Während dieser kurzen Übergabe kann es vorkommen, dass die Gesamtzahl der verwendeten Slots in Ihren Monitoring-Diagrammen kurzzeitig die Gesamtkapazität aller Reservierungen überschreitet. Das ist ein normales und erwartetes Artefakt des Prozesses für die Vorabreservierung und Zuweisung von Slots. Ihnen wird diese vorübergehende zusätzliche Nutzung nicht in Rechnung gestellt.

Angenommen, Sie haben folgende Reservierungseinstellungen:

• project_a ist reservation_a zugewiesen, das 500 Referenz-Slots ohne Autoscaling hat.
• project_b ist reservation_b zugewiesen, das 100 Referenz-Slots ohne Autoscaling hat.
• Beide Reservierungen befinden sich in derselben Region und im selben Verwaltungsprojekt und es sind keine anderen Projekte zugewiesen.

Sie führen query_b in project_b aus. Wenn in project_a keine Abfrage ausgeführt wird, hat query_b Zugriff auf die 500 inaktiven Slots von reservation_a. Solange query_b noch ausgeführt wird, können bis zu 600 Slots belegt werden: 100 Referenz-Slots plus 500 inaktive Slots.

Angenommen, Sie führen während der Ausführung von query_b query_a in project_a aus, das 500 Slots nutzen kann.

• Da Sie 500 Referenz-Slots für project_a reserviert haben, wird query_a sofort gestartet und erhält 500 Slots.
• Die Anzahl der query_b zugewiesenen Slots sinkt schnell auf 100 Referenz-Slots.
• Zusätzliche Abfragen, die in project_b ausgeführt werden, teilen sich diese 100 Slots. Wenn für nachfolgende Abfragen nicht genügend Slots zum Starten vorhanden sind, werden sie in die Warteschlange gestellt, bis die laufenden Abfragen abgeschlossen sind und Slots verfügbar werden.

Wenn project_b in diesem Beispiel einer Reservierung ohne Baseline-Slots oder Autoscaling zugewiesen wurde, hat query_b nach dem Start von query_a keine Slots mehr. BigQuery würde query_b pausieren, bis inaktive Slots verfügbar sind oder die Abfrage abläuft. Zusätzliche Abfragen in project_b werden in die Warteschlange gestellt, bis inaktive Slots verfügbar sind.

Freigabe inaktiver Slots steuern und einschränken

Wenn Sie verhindern möchten, dass eine bestimmte Reservierung inaktive Slots aus anderen Reservierungen ausleiht, setzen Sie das Attribut ignore_idle_slots auf „true“. Diese Einstellung steuert nur das Ausleihen, nicht das Verleihen. Eine Reservierung, bei der ignore_idle_slots auf „true“ gesetzt ist, kann keine Kapazität mehr ausleihen, aber ihre eigenen inaktiven Slots an andere Reservierungen verleihen, die sie benötigen. Solange ignore_idle_slots „false“ ist, kann eine Reservierung mit der Slot-Anzahl 0 trotzdem auf ungenutzte Slots zugreifen.

Zusätzlich zu ignore_idle_slots können Sie die folgenden Mechanismen verwenden, um die Freigabe inaktiver Slots für Ihre Arbeitslasten zu verwalten und zu steuern:

• Reservierungsbasierte Fairness: Inaktive Slots werden gleichmäßig auf Reservierungen und nicht auf einzelne Projekte verteilt. So wird verhindert, dass Arbeitslasten mit mehreren Projekten den Pool inaktiver Slots monopolisieren. Informationen zum Aktivieren dieser Einstellung finden Sie unter Reservierungsbasierte Fairness aktivieren.
• Vorhersagbare Reservierungen: Legen Sie maximale Kapazitätsgrenzen für die Nutzung von Kapazität (einschließlich inaktiver Slots) fest, um eine vorhersagbare Ressourcenskalierung ohne unerwartete Spitzen zu ermöglichen. Die Konfigurationsschritte finden Sie unter Vorhersehbare Reservierung erstellen.
• Reservierungsgruppen: Gruppieren zusammengehörige Reservierungen, um den gesamten Slot-Verbrauch innerhalb der Gruppe zu begrenzen und die Freigabe inaktiver Slots innerhalb der Gruppe vor der Freigabe in der gesamten Organisation zu priorisieren. Informationen zum Einrichten von Gruppen finden Sie unter Reservierungsgruppe erstellen.

Für die Freigabe inaktiver Slots gelten zwei wichtige Einschränkungen:

• Inaktive Slots können nicht zwischen Reservierungen verschiedener Versionen geteilt werden.
• Aufgaben vom Typ ML_EXTERNAL bilden eine Ausnahme, da Slots, die von externen BigQuery ML-Modellerstellungsjobs verwendet werden, nicht auf Abruf sind. Die Slots in einer Reservierung mit den Zuweisungstypen ML_EXTERNAL und QUERY sind nur für andere Abfragejobs verfügbar, wenn die Slots nicht von den ML_EXTERNAL-Jobs belegt werden. Darüber hinaus können diese Jobs keine inaktiven Slots aus anderen Reservierungen verwenden.

Reservierungsbasierte Fairness

Hinweis :Bei Administrationsprojekten, die nach dem 10. Oktober 2026 erstellt wurden, ist die reservierungsbasierte Fairness standardmäßig aktiviert. Für Projekte, die vor dem 10. Oktober 2026 erstellt wurden, müssen Sie die reservierungsbasierte Fairness aktivieren, bevor Sie eine vorhersehbare Reservierung erstellen können.

Bei der reservierungsbasierten Fairness priorisiert und weist BigQuery inaktive Slots gleichmäßig allen Reservierungen innerhalb desselben Administratorprojekts zu, unabhängig von der Anzahl der Projekte, die Jobs in jeder Reservierung ausführen. Jede Reservierung erhält einen ähnlichen Anteil der verfügbaren Kapazität im Leerlauf-Slotpool. Die Slots werden dann fair auf die Projekte verteilt. Diese Funktion wird nur in den Enterprise- oder Enterprise Plus-Versionen unterstützt.

Das folgende Diagramm zeigt, wie inaktive Slots ohne reservierungsbasierte Fairness verteilt werden:

In diesem Diagramm werden inaktive Slots gleichmäßig auf die Projekte verteilt.

Wenn die reservierungsbasierte Fairness nicht aktiviert ist, werden die verfügbaren inaktiven Slots gleichmäßig auf die Projekte innerhalb der Reservierungen verteilt.

Das folgende Diagramm zeigt, wie inaktive Slots verteilt werden, wenn die reservierungsbasierte Fairness aktiviert ist:

In diesem Diagramm werden inaktive Slots gleichmäßig auf Reservierungen und nicht auf Projekte verteilt.

Wenn die reservierungsbasierte Fairness aktiviert ist, werden die verfügbaren inaktiven Slots gleichmäßig auf die Reservierungen verteilt.

Wenn Sie die reservierungsbasierte Fairness aktivieren, sollten Sie Ihren Ressourcenverbrauch prüfen, um die Slot-Verfügbarkeit und die Abfrageleistung zu verwalten.

Verlassen Sie sich bei Produktionsarbeitslasten mit strengen Zeitvorgaben nicht nur auf inaktive Slots. Für diese Jobs müssen Baseline- oder Autoscaling-Slots verwendet werden. Wir empfehlen, inaktive Slots für Jobs mit niedrigerer Priorität zu verwenden, da die Slots jederzeit vorzeitig beendet werden können.

Slot-Autoscaling

Im folgenden Abschnitt wird das Autoscaling von Slots und die Funktionsweise von Reservierungen beschrieben.

Autoscaling-Reservierungen verwenden

Sie müssen keine Slot-Zusicherungen erwerben, bevor Sie Autoscaling-Reservierungen erstellen. Slot-Zusicherungen bieten einen ermäßigten Preis für konsistent verwendete Slots, sind aber bei Autoscaling-Reservierungen optional. Zum Erstellen einer Autoscaling-Reservierung weisen Sie einer Reservierung eine maximale Anzahl von Slots (die maximale Reservierungsgröße) zu. Sie können die maximale Anzahl von Autoscaling-Slots ermitteln. Dazu ziehen Sie die maximale Reservierungsgröße von allen optionalen Referenz-Slots ab, die der Reservierung zugewiesen sind.

Beachten Sie beim Erstellen von Autoscaling-Reservierungen Folgendes:

• BigQuery skaliert Reservierungen nahezu sofort, bis die Anzahl der Slots erreicht ist, die zum Ausführen der Jobs erforderlich sind, oder die maximale Anzahl an für die Reservierung verfügbaren Slots erreicht ist. Slots werden immer automatisch auf ein Vielfaches von 50 skaliert.
• Im Gegensatz zu Baseline-Slots reserviert BigQuery keine Autoscaling-Slots im Voraus. Diese Kapazität, die die Lücke zwischen Ihren Referenz-Slots und der maximalen Reservierungsgröße schließt, hängt von der aktuellen Systemverfügbarkeit ab. In Zeiten hoher Nachfrage kann es aufgrund von Kapazitätsbeschränkungen zu Verzögerungen beim Hochskalieren kommen.
• Die Skalierung nach oben basiert auf der tatsächlichen Nutzung und wird auf die nächste 50-Slot-Schrittweite aufgerundet.
• Ihre automatisch skalierten Slots werden bei der vertikalen Skalierung zum Preis für die Kapazitätsberechnung für Ihre Version abgerechnet. Ihnen wird die Anzahl der skalierten Slots in Rechnung gestellt, nicht die Anzahl der verwendeten Slots. Diese Gebühr gilt auch dann, wenn der Job, der BigQuery hochskaliert, fehlschlägt. Verwenden Sie daher nicht das Informationsschema für Jobs, um die Abrechnung abzugleichen. Weitere Informationen finden Sie unter Autoscaling mit Informationsschema überwachen.
• Die Skalierung der Anzahl der Slots erfolgt zwar immer in Schritten von 50, es können aber auch mehr als 50 Slots in einem Schritt skaliert werden. Wenn Ihre Arbeitslast beispielsweise zusätzliche 450 Slots benötigt, kann BigQuery versuchen, gleichzeitig um 450 Slots zu skalieren, um die Kapazitätsanforderungen zu erfüllen.
• BigQuery skaliert herunter, wenn die mit der Reservierung verknüpften Jobs die Kapazität nicht mehr benötigen. Standardmäßig wird die Kapazität pro Sekunde mit einer Mindestdauer von einer Minute abgerechnet. Sie können die fluide Skalierung von BigQuery auf Reservierungsebene aktivieren, um eine sekundengenaue Abrechnung ohne Mindestdauer zu erhalten.

Hinweis: Es kann einige Sekunden dauern, bis Änderungen am Wert für die maximale Anzahl von Slots für eine Reservierung wirksam werden.

Die automatisch skalierte Kapazität wird mindestens 60 Sekunden lang beibehalten. Dieser Zeitraum von 60 Sekunden wird als Herunterskalierungsfenster bezeichnet. Bei einem neuen Kapazitätsspitzen wird das Fenster für das Herunterskalieren zurückgesetzt und die gesamte Kapazitätsstufe wird als neuer Zuschuss behandelt. Wenn jedoch seit der letzten Kapazitätssteigerung mindestens 60 Sekunden vergangen sind und die Nachfrage sinkt, reduziert das System die Kapazität, ohne das Fenster für das Herunterskalieren zurückzusetzen. So sind aufeinanderfolgende Herunterskalierungen ohne Verzögerung möglich.

Wenn Ihre anfängliche Arbeitslastkapazität beispielsweise auf 100 Slots skaliert wird, wird der Spitzenwert mindestens 60 Sekunden lang beibehalten. Wenn Ihre Arbeitslast während dieses Herunterskalierungsfensters auf einen neuen Höchstwert von 200 Slots skaliert wird, beginnt ein neues Herunterskalierungsfenster für 60 Sekunden. Wenn es während dieses Zeitraums keine neue Spitze gibt, wird die Arbeitslast nach 60 Sekunden herunterskaliert.

Betrachten Sie das folgende detaillierte Beispiel: Um 12:00:00 Uhr wird Ihre anfängliche Kapazität auf 100 Slots skaliert und die Nutzung dauert eine Sekunde. Dieser Spitzenwert wird ab 12:00:00 Uhr mindestens 60 Sekunden lang beibehalten. Nach Ablauf der 60 Sekunden (um 12:01:01 Uhr) wird BigQuery auf 50 Slots herunterskaliert, wenn die neue Nutzung 50 Slots beträgt. Wenn die neue Nutzung um 12:01:02 Uhr 0 Slots beträgt, skaliert BigQuery sofort wieder auf 0 Slots herunter. Nach Ablauf des Zeitraums für das Herunterskalieren kann BigQuery mehrmals hintereinander herunterskaliert werden, ohne dass ein neuer Zeitraum für das Herunterskalieren erforderlich ist.

Fluide Skalierung in BigQuery

Bei der fluiden Skalierung von BigQuery entfällt die Mindestdauer von einer Minute, die beim Standard-Autoscaling erforderlich ist. Die Slotkapazität wird von Sekunde zu Sekunde angepasst. Diese Funktion ändert nichts an den Skalierungsschritten von 50 Slots.

Um sich schnell an die Anforderungen von Reservierungen anzupassen, wirkt sich die dynamische Skalierung von BigQuery auf die Verteilung der Freigabe von Leerlauf-Slots zwischen Reservierungen über kurze Zeiträume hinweg aus. Dies führt dazu, dass etwas mehr oder weniger Leerlauf-Slots als der genaue faire Anteil einer Reservierung zugewiesen werden.

Eine Anleitung zum Aktivieren dieser Funktion finden Sie unter Reservierungen aktualisieren.

Bei Reservierungen mit verwalteter Notfallwiederherstellung muss die fluide Skalierung von BigQuery sowohl in der primären als auch in der sekundären Region aktiviert sein, damit nach einem Failover eine sekundengenaue Abrechnung möglich ist.

Informationen zur Arbeit mit Autoscaling finden Sie unter Arbeitslastreservierungen verwalten.

Reservierungen mit Baseline- und Autoscaling-Slots verwenden

Zusätzlich zur maximalen Reservierungsgröße können Sie optional eine Basisanzahl von Slots pro Reservierung angeben. Die Referenz ist die Mindestanzahl an Slots, die immer der Reservierung zugewiesen werden. Diese werden Ihnen immer in Rechnung gestellt. Autoscaling-Slots werden erst hinzugefügt, wenn alle Referenz-Slots (und gegebenenfalls inaktive Slots) verbraucht wurden. Sie können inaktive Referenz-Slots in einer Reservierung für andere Reservierungen freigeben, die Kapazitäten benötigen.

Sie können die Anzahl der Referenz-Slots in einer Reservierung alle paar Minuten erhöhen, sofern BigQuery bei der Anfrage über freie Kapazität verfügt. Wenn Sie die Referenz-Slots verringern möchten, ist die Anzahl auf eine Stunde begrenzt, wenn Sie die Kapazität der Referenz-Slots kürzlich geändert haben und die Referenz-Slots die zugesicherten Slots überschreiten. Andernfalls können Sie die Referenz-Slots alle paar Minuten verringern.

Referenz- und Autoscaling-Slots sollen Kapazitäten basierend auf Ihrer letzten Arbeitslast bereitstellen. Wenn Sie eine ungewöhnlich große Arbeitslast erwarten, empfehlen wir, Ihre Referenzkapazität rechtzeitig vor dem Ereignis zu erhöhen, anstatt sich auf Autoscaling-Slots zu verlassen. Da Baseline-Steigerungen davon abhängen, ob in BigQuery Kapazität verfügbar ist, haben Sie die besten Chancen, die benötigten Slots zu erhalten, wenn Sie im Voraus planen. Wenn Ihre Anfrage zur Erhöhung der Kapazität fehlschlägt, warten Sie 15 Minuten und versuchen Sie es dann noch einmal.

Wenn die Reservierung keine Referenz-Slots hat oder nicht so konfiguriert ist, dass inaktive Slots aus anderen Reservierungen übernommen werden, versucht BigQuery zu skalieren. Andernfalls müssen Referenz-Slots vor der Skalierung vollständig ausgelastet sein.

Reservierungen verwenden und fügen Slots in der folgenden Priorität hinzu:

1. Referenz-Slots:
2. Freigabe inaktiver Slots (falls aktiviert). Reservierungen können nur inaktive Referenz- oder zugesicherte Slots aus anderen Reservierungen teilen, die mit derselben Version und in derselben Region erstellt wurden.
3. Autoscaling-Slots:

Im folgenden Beispiel werden Slots von einem angegebenen Referenzbetrag skaliert. Die Reservierungen etl und dashboard haben eine Basisgröße von 700 bzw. 300 Slots.

In diesem Beispiel kann die Reservierung etl auf 1.300 Slots (700 Referenz-Slots plus 600 Autoscaling-Slots) skaliert werden. Wenn die Reservierung dashboard nicht verwendet wird, kann die Reservierung etl die 300 Slots aus der Reservierung dashboard verwenden, wenn dort kein Job ausgeführt wird, was zu einer maximalen Anzahl von 1600 möglichen Slots führt.

Die Reservierung dashboard kann auf 1.100 Slots (300 Referenz-Slots plus 800 Autoscaling-Slots) skaliert werden. Wenn die Reservierung etl vollständig inaktiv ist, kann die Reservierung dashboard auf maximal 1.800 Slots skaliert werden (300 Baseline-Slots plus 800 Autoscale-Slots plus 700 ungenutzte Slots in der etl-Reservierung).

Wenn für die etl-Reservierung mehr als 700 Referenz-Slots erforderlich sind, die immer verfügbar sind, wird versucht, Slots mit den folgenden Methoden der Reihe nach hinzuzufügen:

1. 700 Referenz-Slots:
2. Inaktiver Slot mit den 300 Referenz-Slots in der dashboard-Reservierung. Ihre Reservierung teilt nur inaktive Referenz-Slots mit anderen Reservierungen, die mit derselben Version erstellt werden.
3. 600 zusätzliche Slots auf die maximale Reservierungsgröße hochskalieren

Slot-Zusicherungen verwenden

Das folgende Beispiel zeigt das Autoscaling von Slots mit Kapazitätszusicherungen.

Wie Reservierungs-Baselines können Sie mit Slot-Zusicherungen eine feste Anzahl an Slots zuweisen, die allen Reservierungen zur Verfügung stehen. Im Gegensatz zu Referenz-Slots kann eine Zusicherung während der Laufzeit nicht reduziert werden. Slot-Zusicherungen sind optional, können jedoch Kosten sparen, wenn Referenz-Slots für einen längeren Zeitraum erforderlich sind. Slot-Zusicherungen werden verwendet, um Referenzslots für Ihre Reservierungen abzudecken. Nicht genutzte Slot-Kapazität wird dann als inaktive Slots für andere Reservierungen freigegeben. Slotzusicherungen gelten nicht für Autoscaling-Slots. Damit Sie den rabattierten Preis für Ihre zugesicherten Slots erhalten, müssen Ihre Slot-Zusicherungen ausreichen, um Ihre Baseline-Slots abzudecken.

In diesem Beispiel wird Ihnen ein vordefinierter Preis für die Slots für die Kapazitätszusicherung berechnet. Ihnen wird die Autoscaling-Rate für die Anzahl der Autoscaling-Slots in Rechnung gestellt, nachdem Autoscaling aktiviert ist und Reservierungen sich in einem erweiterten Status befinden. Ihnen wird die Autoscaling-Rate für die Anzahl der skalierten Slots in Rechnung gestellt, nicht die Anzahl der verwendeten Slots.

Im folgenden Beispiel sehen Sie Reservierungen, bei denen die Anzahl der Referenzslots die Anzahl der zugesicherten Slots übersteigt.

In diesem Beispiel gibt es insgesamt 1.000 Referenz-Slots in den beiden Reservierungen, 500 aus der Reservierung etl und 500 aus der Reservierung dashboard. Die Zusicherung deckt jedoch nur 800 Slots ab. In diesem Fall werden die zusätzlichen Slots zum PAYG-Preis (Pay as you go) abgerechnet.

Maximal verfügbare Slots

Sie können die maximale Anzahl von Slots, die eine Reservierung verwenden kann, berechnen. Dazu fügen Sie die Referenz-Slots, die maximale Anzahl von Autoscaling-Slots und alle Slots in Zusicherungen hinzu, die mit der gleichen Version erstellt wurden und nicht durch die Referenz-Slots abgedeckt sind. Das folgende Beispiel wird so eingerichtet:

• Eine Kapazitätszusicherung von 1.000 Slots pro Jahr. Diese Slots werden in der Reservierung etl und der Reservierung dashboard als Referenz-Slots zugewiesen.
• 700 Referenz-Slots, die der Reservierung etl zugewiesen sind.
• 300 Referenz-Slots, die der Reservierung dashboard zugewiesen sind.
• Skalieren Sie Slots von 600 für die Reservierung etl automatisch.
• Skalieren Sie Slots von 800 für die Reservierung dashboard automatisch.

Für die Reservierung etl entspricht die maximal mögliche Anzahl von Slots den etl-Referenz-Slots (700) plus den Referenz-Slots dashboard (300, wenn alle Slots inaktiv sind) plus der maximalen Anzahl von Autoscale-Slots (600). Die maximale Anzahl von Slots, die die Reservierung etl in diesem Beispiel verwenden könnte, ist also 1.600. Diese Zahl überschreitet die Zahl in der Kapazitätszusicherung.

Im folgenden Beispiel überschreitet die jährliche Zusicherung die zugewiesenen Referenz-Slots.

In diesem Beispiel ist:

• Eine Kapazitätszusicherung von 1.600 Slots pro Jahr.
• Maximale Reservierungsgröße von 1.500 (einschließlich 500 Autoscaling-Slots).
• 1.000 Referenz-Slots, die der Reservierung etl zugewiesen sind.

Die maximale Anzahl der für die Reservierung verfügbaren Slots entspricht den Referenz-Slots (1.000) plus der Anzahl der zugesicherten inaktiven Slots, die nicht den Referenz-Slots zugeordnet sind (1.600 Slots pro Jahr – 1.000 Referenz-Slots = 600) plus der Anzahl der Autoscaling-Slots (500). Die maximalen potenzielle Slots in dieser Reservierung beträgt also 2.100. Die automatisch skalierten Slots sind zusätzliche Slots, die über die Kapazitätszusicherung hinausgehen.

BigQuery kann manchmal die verfügbare BigQuery-Systemkapazität nutzen, um Ihre Abfrage schneller zu verarbeiten, als es Ihr Slotlimit normalerweise zulässt. In diesem Fall verzögert BigQuery die Rückgabe der endgültigen Abfrageergebnisse, bis Ihre Standard-Slot-Kapazität die Nutzungsspitze abdeckt. So wird sichergestellt, dass Ihnen nie mehr als Ihr Limit in Rechnung gestellt wird, während die gesamte genutzte Rechenleistung berücksichtigt wird.

Best Practices für das Autoscaling

• Legen Sie bei der erstmaligen Verwendung des Autoscalings die Anzahl der Autoscaling-Slots anhand der bisherigen und erwarteten Leistung auf einen sinnvollen Wert fest. Beobachten Sie nach dem Erstellen der Reservierung aktiv die Fehlerrate, Leistung und Rechnung und passen Sie die Anzahl der Autoscaling-Slots nach Bedarf an.

• Das Autoscaling hat ein Minimum von einer Minute vor dem Herunterskalieren. Daher ist es wichtig, die maximale Anzahl von automatisch skalierten Slots festzulegen, um ein Gleichgewicht zwischen Leistung und Kosten zu schaffen. Wenn die maximale Anzahl von Autoscaling-Slots zu groß ist und Ihr Job alle Slots verwenden kann, um einen Job in Sekunden abzuschließen, fallen dennoch Kosten für die maximale Anzahl an Slots für die volle Minute an. Wenn Sie die maximale Anzahl von Slots auf die Hälfte des aktuellen Werts senken, wird Ihre Reservierung auf eine niedrigere Anzahl skaliert und der Job kann in dieser Minute mehr slot_seconds nutzen, was die Auslastung reduziert. Informationen zum Ermitteln der Slot-Anforderungen finden Sie unter Jobleistung überwachen. Eine alternative Möglichkeit zur Bestimmung Ihrer Slotanforderungen finden Sie unter Slot-Empfehlungen für Editionen ansehen.

• Die Slot-Nutzung kann gelegentlich die Summe Ihrer Referenz plus der skalierten Slots überschreiten. Ihnen wird keine Slot-Nutzung in Rechnung gestellt, die über Ihrer Referenz liegt, plus die skalierten Slots.

• Autoscaling ist am besten für große Arbeitslasten mit langer Laufzeit geeignet, z. B. für Arbeitslasten mit mehreren gleichzeitigen Abfragen. Vermeiden Sie das Senden einzelner Abfragen, da jede Abfrage die Reservierung skaliert, bei der sie für mindestens eine Minute skaliert wird. Wenn Sie kontinuierlich Abfragen senden, was eine konstante Arbeitslast verursacht, erhalten Sie durch Festlegen einer Referenz und Kauf einer Zusicherung eine konstante Kapazität zu einem reduzierten Preis.

• BigQuery-Autoscaling unterliegt der Kapazitätsverfügbarkeit. BigQuery versucht, die Kapazitätsanforderungen der Kunden anhand der bisherigen Nutzung zu erfüllen. Sie können eine optionale Slot-Baseline festlegen, damit Slots sofort verfügbar sind. Mit Baselines bezahlen Sie für sie, unabhängig davon, ob Sie sie verwenden oder nicht. Wenden Sie sich einige Wochen im Voraus an das BigQuery-Team, damit die Kapazität für große, unorganische Anforderungen, z. B. an Feiertagen mit hohem Traffic, verfügbar ist.

• Für Baseline-Slots werden immer Gebühren berechnet. Wenn eine Kapazitätszusicherung abläuft, müssen Sie möglicherweise die Anzahl der Baseline-Slots in Ihren Reservierungen manuell anpassen, um unerwünschte Gebühren zu vermeiden. Beispiel: Sie haben eine 1-jährige Zusicherung mit 100 Slots und eine Reservierung mit 100 Baseline-Slots. Die Zusicherung läuft ab und hat keinen Verlängerungstarif. Nach Ablauf der Zusicherung zahlen Sie für 100 Baseline-Slots zum Pay-As-You-Go-Preis.

Beobachtbarkeit

Informationen zum Monitoring der Slot-Nutzung und der Jobleistung mit Autoscaling finden Sie unter Autoscaling überwachen.