Présentation de l'autoscaling des emplacements
Les réservations que vous configurez pour utiliser l'autoscaling des emplacements effectuent un scaling automatique de la capacité allouée en fonction de vos charges de travail. À mesure que votre charge de travail augmente ou diminue, BigQuery ajuste dynamiquement vos emplacements au niveau approprié. Les réservations avec autoscaling des emplacements ne sont disponibles qu'avec les éditions BigQuery.
Utiliser les réservations d'autoscaling
Vous n'avez pas besoin de souscrire des engagements d'emplacements avant de créer des réservations d'autoscaling. Les engagements d'emplacements offrent un tarif réduit pour les emplacements utilisés de manière cohérente, mais sont facultatifs avec les réservations d'autoscaling. Pour créer une réservation d'autoscaling, vous attribuez à une réservation un nombre maximal d'emplacements (la taille maximale de la réservation). Vous pouvez identifier le nombre maximal d'emplacements d'autoscaling en soustrayant la taille de réservation maximale de tous les emplacements de référence facultatifs attribués à la réservation.
Lorsque vous créez des réservations d'autoscaling, tenez compte des points suivants :
- BigQuery procède au scaling des réservations presque instantanément jusqu'à ce qu'il atteigne le nombre d'emplacements requis pour exécuter les jobs, ou le nombre maximal d'emplacements disponibles pour la réservation. Les emplacements sont toujours ajustés automatiquement à un multiple de 50.
- L'augmentation est basée sur l'utilisation réelle et est arrondie à la tranche de 50 emplacements la plus proche.
- Vos emplacements avec autoscaling sont facturés selon les tarifs des calculs de capacité de votre édition associée lors du scaling à la hausse. Vous êtes facturé pour le nombre d'emplacements avec scaling, et non pour le nombre d'emplacements utilisés. Ces frais s'appliquent même si la tâche qui entraîne le scaling à la hausse de BigQuery échoue.
- Bien que le nombre d'emplacements évolue toujours par multiples de 50, le scaling peut ajouter plus de 50 emplacements en une seule fois. Par exemple, si votre charge de travail nécessite 450 emplacements supplémentaires, BigQuery peut tenter de procéder à un scaling à la hausse avec 450 emplacements en une seule fois pour répondre à la demande de capacité.
- BigQuery réduit la capacité lorsque les jobs associés à la réservation n'ont plus besoin de la capacité (avec un minimum d'une minute).
Toute capacité à autoscaling est conservée pendant au moins 60 secondes. Cette période de 60 secondes est appelée "fenêtre de réduction". Tout pic de capacité réinitialise la fenêtre de réduction de la capacité, en considérant l'ensemble du niveau de capacité comme une nouvelle autorisation. Toutefois, si 60 secondes ou plus se sont écoulées depuis la dernière augmentation de la capacité et que la demande est moins importante, le système réduit la capacité sans réinitialiser la fenêtre de réduction, ce qui permet des diminutions consécutives sans délai imposé.
Pour savoir comment utiliser l'autoscaling, consultez la section Utiliser l'autoscaling des emplacements.
Utiliser des réservations avec des emplacements de référence et d'autoscaling
En plus de spécifier la taille de réservation maximale, vous pouvez éventuellement spécifier un nombre de référence d'emplacements par réservation. Le nombre de référence correspond au nombre minimal d'emplacements qui seront toujours alloués à la réservation. Ces emplacements vous seront toujours facturés. Les emplacements d'autoscaling ne sont ajoutés qu'après la consommation de tous les emplacements de référence (et les emplacements inactifs, le cas échéant). Vous pouvez partager des emplacements de référence inactifs dans une réservation avec d'autres réservations nécessitant plus de capacité.
Vous pouvez augmenter le nombre d'emplacements de référence dans une réservation toutes les deux ou trois minutes. Si vous souhaitez réduire le nombre d'emplacements de référence, vous ne pouvez le faire qu'une fois par heure si vous avez récemment modifié votre capacité d'emplacements de référence et que vos emplacements de référence dépassent vos emplacements sur engagement. Autrement, vous pouvez réduire vos emplacements de référence toutes les deux ou trois minutes.
Les emplacements de référence et d'autoscaling sont destinés à fournir de la capacité en fonction de votre charge de travail récente. Si vous prévoyez une charge de travail importante très différente de vos charges de travail récentes, nous vous recommandons d'augmenter votre capacité de référence avant qu'elle ne survienne plutôt que de vous appuyer sur des emplacements d'autoscaling pour couvrir la capacité de charge de travail. Si vous rencontrez un problème lors de l'augmentation de votre capacité de base, relancez la requête après 15 minutes.
Si la réservation ne comporte pas d'emplacements de référence ou n'est pas configurée pour emprunter des emplacements inactifs à partir d'autres réservations, BigQuery tente d'effectuer le scaling. Autrement, les emplacements de référence doivent être pleinement utilisés avant le scaling.
Les réservations utilisent et ajoutent des emplacements dans l'ordre de priorité suivant :
- Nombre d'emplacements de base.
- Partage d'emplacements inactifs (si cette option est activée). Les réservations ne peuvent partager que des emplacements de référence inactifs ou des emplacements sur engagement d'autres réservations créées avec la même édition et la même région.
- Emplacements liés à l'autoscaling.
Dans l'exemple suivant, le nombre d'emplacements s'ajuste à partir d'une quantité de référence spécifiée. Les réservations etl et dashboard ont respectivement une taille de référence de 700 et 300 emplacements.
Dans cet exemple, la réservation etl peut évoluer jusqu'à 1 300 emplacements (700 emplacements de référence et 600 emplacements liés à l'autoscaling). Si la réservation dashboard n'est pas utilisée, la réservation etl peut utiliser les 300 emplacements de la réservation dashboard si aucun job les concernant n'est en cours d'exécution, ce qui conduit à un maximum de 1 600 emplacements possibles.
La réservation dashboard peut évoluer jusqu'à 1 100 emplacements (300 emplacements de référence et 800 emplacements liés à l'autoscaling). Si la réservation etl est complètement inactive, la réservation dashboard peut évoluer jusqu'à un maximum de 1 800 emplacements (300 emplacements de référence, 800 emplacements liés à l'autoscaling et 700 emplacements inactifs dans la réservation etl).
Si la réservation etl nécessite plus de 700 emplacements de référence, qui sont toujours disponibles, elle tente d'ajouter des emplacements en utilisant les méthodes suivantes dans l'ordre :
- 700 emplacements de référence.
- Partage des emplacements inactifs avec les 300 emplacements de référence dans la réservation
dashboard. Votre réservation ne partage que les emplacements de référence inactifs avec d'autres réservations créées avec la même édition. - Scaling à la hausse de 600 emplacements supplémentaires jusqu'à la taille maximale de la réservation.
Utiliser des engagements d'emplacements
L'exemple suivant illustre l'autoscaling des emplacements à l'aide d'engagements de capacité.
À l'instar des valeurs de référence de réservation, les engagements d'emplacements vous permettent d'allouer un nombre fixe d'emplacements disponibles à toutes les réservations. Contrairement aux emplacements de référence, un engagement ne peut pas être réduit pendant la durée de l'engagement. Les engagements d'emplacements sont facultatifs mais peuvent réduire les coûts si des emplacements de référence sont requis pour de longues périodes.
Dans cet exemple, vous êtes facturé selon un tarif prédéfini pour les emplacements d'engagement de capacité. Vous êtes facturé au tarif de l'autoscaling pour le nombre d'emplacements d'autoscaling après l'activation de l'autoscaling et l'ajustement des réservations. Pour le taux d'autoscaling, le nombre d'emplacements mis à l'échelle vous est facturé, et non le nombre d'emplacements utilisés.
Nombre maximal d'emplacements disponibles
Vous pouvez calculer le nombre maximal d'emplacements qu'une réservation peut utiliser en additionnant les emplacements de référence, le nombre maximal d'emplacements avec autoscaling et tous les emplacements dans les engagements qui ont été créés avec la même édition et qui ne sont pas couverts par les emplacements de référence. L'exemple de l'image précédente est configuré comme suit :
- Un engagement de capacité de 1 000 emplacements annuels. Ces emplacements sont attribués en tant qu'emplacements de référence dans la réservation
etlet la réservationdashboard. - 700 emplacements de référence attribués à la réservation
etl. - 300 emplacements de référence attribués à la réservation
dashboard. - 600 emplacements liés à l'autoscaling pour la réservation
etl. - 800 emplacements liés à l'autoscaling pour la réservation
dashboard.
Pour la réservation etl, le nombre maximal d'emplacements possible est égal au nombre d'emplacements de référence etl (700), plus le nombre d'emplacements de référence dashboard (300, si tous les emplacements sont inactifs), plus le nombre maximal d'emplacements liés à l'autoscaling (600). Le nombre maximal d'emplacements que la réservation etl peut utiliser dans cet exemple est donc de 1 600. Ce nombre dépasse celui de l'engagement de capacité.
Dans l'exemple suivant, l'engagement annuel dépasse le nombre d'emplacements de référence attribués.
Dans cet exemple, nous avons :
- Un engagement de capacité de 1 600 emplacements annuels.
- Une taille de réservation maximale de 1 500 (y compris 500 emplacements d'autoscaling).
- 1 000 emplacements de référence attribués à la réservation
etl.
Le nombre maximal d'emplacements disponibles pour la réservation est égal au nombre d'emplacements de référence (1 000), plus tous les emplacements inactifs sur engagement qui ne sont pas dédiés aux emplacements de référence (1 600 emplacements annuels - 1 000 emplacements de référence = 600), plus le nombre d'emplacements d'autoscaling (500). Le nombre maximal d'emplacements potentiels dans cette réservation est donc de 2 100. Les emplacements avec autoscaling sont des emplacements supplémentaires qui dépassent l'engagement de capacité.
Bonnes pratiques en matière d'autoscaling
Lors de la première utilisation de l'autoscaler, définissez le nombre d'emplacements d'autoscaling sur un nombre significatif en fonction des performances passées et attendues. Une fois la réservation créée, surveillez activement le taux d'échec, les performances et la facturation, puis ajustez le nombre d'emplacements d'autoscaling si nécessaire.
L'autoscaler dispose d'une durée minimale de 1 minute avant le scaling à la baisse. Il est donc important de définir le nombre maximal d'emplacements à scaling automatique pour trouver un équilibre entre les performances et les coûts. Si le nombre maximal d'emplacements avec autoscaling est trop élevé et que votre tâche peut utiliser tous les emplacements pour terminer une tâche en quelques secondes, vous devrez tout de même payer le coût des emplacements maximum pendant toute la minute. Si vous réduisez le nombre maximal d'emplacements à la moitié de la valeur actuelle, votre réservation est réduite et la tâche peut utiliser plus de
slot_secondsau cours de cette minute, ce qui réduit le gaspillage. Pour déterminer vos besoins en termes d'emplacements, consultez Surveiller les performances des tâches. Pour une autre approche pour déterminer vos besoins en termes d'emplacements, consultez Afficher les recommandations d'emplacements d'édition.Le nombre d'emplacements utilisés peut parfois dépasser la somme de vos emplacements de base et de vos emplacements avec autoscaling. Les emplacements excédentaires (par rapport à la somme de vos emplacements de base et de vos emplacements avec autoscaling) ne vous sont pas facturés.
L'autoscaler est plus efficace pour les charges de travail lourdes et de longue durée, telles que les charges de travail comportant plusieurs requêtes simultanées. Évitez d'envoyer des requêtes une par une, car chaque requête adapte la réservation, qui reste adaptée pendant au moins une minute. Si vous envoyez des requêtes en continu, ce qui entraîne une charge de travail constante, la définition d'une référence et l'achat d'un engagement vous permettent de bénéficier d'une capacité constante à un prix réduit.
L'autoscaling BigQuery est soumis à une disponibilité de capacité. BigQuery tente de répondre à la demande de capacité des clients en fonction de l'historique d'utilisation. Pour obtenir des garanties de capacité, vous pouvez définir une base d'emplacements facultative, qui correspond au nombre d'emplacements garantis dans une réservation. Les références sont disponibles immédiatement et doivent être payées que vous les utilisiez ou non. Pour vous assurer de la capacité suffisante pour les demandes importantes et peu organiques (telles que les jours fériés), contactez l'équipe BigQuery plusieurs semaines à l'avance.
Les emplacements de base sont toujours facturés. Si un engagement de capacité expire, vous devrez peut-être ajuster manuellement la quantité d'emplacements de base dans vos réservations afin d'éviter des frais inutiles. Par exemple, supposons que vous disposez d'un engagement d'un an avec 100 emplacements et une réservation avec 100 emplacements de base. L'engagement expire et n'offre pas d'option de renouvellement. Une fois l'engagement expiré, vous payez 100 emplacements de base au tarif à l'utilisation.
Surveiller l'autoscaling
Lorsque vous surveillez l'utilisation des emplacements avec des graphiques de ressources d'administration, vous pouvez constater une augmentation du nombre d'emplacements mis à l'échelle par rapport à votre utilisation d'emplacements, car les graphiques lissent le nombre d'emplacements utilisés pendant la période d'alignement. Pour afficher l'utilisation des emplacements avec autoscaling plus précisément, réduisez l'option de période. Cette action met automatiquement à jour la période d'alignement pour utiliser un incrément plus petit.
Dans l'exemple suivant, le graphique affiche un nombre d'emplacements mis à l'échelle bien plus important que la demande de la charge de travail.
Toutefois, si vous réduisez l'option de période afin que la période d'alignement soit de deux secondes, vous pouvez constater que l'autoscaler s'adapte à la demande de la charge de travail et affiche des données plus précises. Vous pouvez ajuster l'option de période en faisant glisser les plages de début et de fin de l'option de période. Pour afficher les données de demande de charge de travail les plus précises, sélectionnez p99 dans la liste Métrique.
Pour obtenir une vue plus précise de l'utilisation de l'autoscaling, utilisez une période d'alignement comprise entre 1 et 15 secondes. Pour en savoir plus sur la période d'alignement des graphiques de ressources administratives, consultez la section Option de période.
Pour en savoir plus sur l'affichage de l'utilisation des emplacements, consultez la section Afficher les graphiques des ressources d'administration.
Surveiller l'autoscaling à l'aide d'un schéma d'informations
Vous pouvez utiliser les scripts SQL suivants pour vérifier les secondes d'utilisation des emplacements facturées pour une édition spécifique. Vous devez exécuter ces scripts dans le projet dans lequel les réservations ont été créées. Le premier script indique les secondes d'utilisation d'emplacements facturées qui sont couvertes par le plan commitment_plan, tandis que le second indique les secondes d'utilisation d'emplacements facturées qui ne sont pas couvertes par un engagement.
Il vous suffit de définir la valeur de trois variables pour exécuter ces scripts :
start_timeend_timeedition_to_check
Les mises en garde suivantes s'appliquent à ces scripts :
Les réservations et les engagements de capacité supprimés sont également supprimés des vues de schéma d'informations, à la fin de la période de conservation des données. Pour obtenir des résultats corrects, spécifiez une période récente ne contenant pas de réservations et d'engagements supprimés.
Le résultat des scripts peut ne pas correspondre exactement à la facture en raison de petites erreurs d'arrondi.
Le script suivant vérifie l'utilisation des emplacements qui est couverte par des engagements, pour une édition spécifique.
Développer pour afficher le script correspondant aux scénarios avec couverture par un engagement
DECLARE start_time,end_time TIMESTAMP; DECLARE edition_to_check STRING; /* Google uses Pacific Time to calculate the billing period for all customers, regardless of their time zone. Use the following format if you want to match the billing report. Change the start_time and end_time values to match the desired window. */ /* The following three variables (start_time, end_time, and edition_to_check) are the only variables that you need to set in the script. During daylight savings time, the start_time and end_time variables should follow this format: 2024-02-20 00:00:00-08. */ SET start_time = "2023-07-20 00:00:00-07"; SET end_time = "2023-07-28 00:00:00-07"; SET edition_to_check = 'ENTERPRISE'; /* The following function returns the slot seconds for the time window between two capacity changes. For example, if there are 100 slots between (2023-06-01 10:00:00, 2023-06-01 11:00:00), then during that window the total slot seconds will be 100 * 3600. This script calculates a specific window (based on the variables defined above), which is why the following script includes script_start_timestamp_unix_millis and script_end_timestamp_unix_millis. */ CREATE TEMP FUNCTION GetSlotSecondsBetweenChanges( slots FLOAT64, range_begin_timestamp_unix_millis FLOAT64, range_end_timestamp_unix_millis FLOAT64, script_start_timestamp_unix_millis FLOAT64, script_end_timestamp_unix_millis FLOAT64) RETURNS INT64 LANGUAGE js AS r""" if (script_end_timestamp_unix_millis < range_begin_timestamp_unix_millis || script_start_timestamp_unix_millis > range_end_timestamp_unix_millis) { return 0; } var begin = Math.max(script_start_timestamp_unix_millis, range_begin_timestamp_unix_millis) var end = Math.min(script_end_timestamp_unix_millis, range_end_timestamp_unix_millis) return slots * Math.ceil((end - begin) / 1000.0) """; /* Sample CAPACITY_COMMITMENT_CHANGES data (unrelated columns ignored): +---------------------+------------------------+-----------------+--------+------------+--------+ | change_timestamp | capacity_commitment_id | commitment_plan | state | slot_count | action | +---------------------+------------------------+-----------------+--------+------------+--------+ | 2023-07-20 19:30:27 | 12954109101902401697 | ANNUAL | ACTIVE | 100 | CREATE | | 2023-07-27 22:29:21 | 11445583810276646822 | FLEX | ACTIVE | 100 | CREATE | | 2023-07-27 23:10:06 | 7341455530498381779 | MONTHLY | ACTIVE | 100 | CREATE | | 2023-07-27 23:11:06 | 7341455530498381779 | FLEX | ACTIVE | 100 | UPDATE | The last row indicates a special change from MONTHLY to FLEX, which happens because of commercial migration. */ WITH /* Information containing which commitment might have plan updated (e.g. renewal or commercial migration). For example: +------------------------+------------------+--------------------+--------+------------+--------+-----------+----------------------------+ | change_timestamp | capacity_commitment_id | commitment_plan | state | slot_count | action | next_plan | next_plan_change_timestamp | +---------------------+------------------------+-----------------+--------+------------+--------+-----------+----------------------------+ | 2023-07-20 19:30:27 | 12954109101902401697 | ANNUAL | ACTIVE | 100 | CREATE | ANNUAL | 2023-07-20 19:30:27 | | 2023-07-27 22:29:21 | 11445583810276646822 | FLEX | ACTIVE | 100 | CREATE | FLEX | 2023-07-27 22:29:21 | | 2023-07-27 23:10:06 | 7341455530498381779 | MONTHLY | ACTIVE | 100 | CREATE | FLEX | 2023-07-27 23:11:06 | | 2023-07-27 23:11:06 | 7341455530498381779 | FLEX | ACTIVE | 100 | UPDATE | FLEX | 2023-07-27 23:11:06 | */ commitments_with_next_plan AS ( SELECT *, IFNULL( LEAD(commitment_plan) OVER ( PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC ), commitment_plan) next_plan, IFNULL( LEAD(change_timestamp) OVER ( PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC ), change_timestamp) next_plan_change_timestamp FROM `region-us.INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT` ), /* Insert a 'DELETE' action for those with updated plans. The FLEX commitment '7341455530498381779' is has no 'CREATE' action, and is instead labeled as an 'UPDATE' action. For example: +---------------------+------------------------+-----------------+--------+------------+--------+ | change_timestamp | capacity_commitment_id | commitment_plan | state | slot_count | action | +---------------------+------------------------+-----------------+--------+------------+--------+ | 2023-07-20 19:30:27 | 12954109101902401697 | ANNUAL | ACTIVE | 100 | CREATE | | 2023-07-27 22:29:21 | 11445583810276646822 | FLEX | ACTIVE | 100 | CREATE | | 2023-07-27 23:10:06 | 7341455530498381779 | MONTHLY | ACTIVE | 100 | CREATE | | 2023-07-27 23:11:06 | 7341455530498381779 | FLEX | ACTIVE | 100 | UPDATE | | 2023-07-27 23:11:06 | 7341455530498381779 | MONTHLY | ACTIVE | 100 | DELETE | */ capacity_changes_with_additional_deleted_event_for_changed_plan AS ( SELECT next_plan_change_timestamp AS change_timestamp, project_id, project_number, capacity_commitment_id, commitment_plan, state, slot_count, 'DELETE' AS action, commitment_start_time, commitment_end_time, failure_status, renewal_plan, user_email, edition, is_flat_rate, FROM commitments_with_next_plan WHERE commitment_plan <> next_plan UNION ALL SELECT * FROM `region-us.INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT` ), /* The committed_slots change the history. For example: +---------------------+------------------------+------------------+-----------------+ | change_timestamp | capacity_commitment_id | slot_count_delta | commitment_plan | +---------------------+------------------------+------------------+-----------------+ | 2023-07-20 19:30:27 | 12954109101902401697 | 100 | ANNUAL | | 2023-07-27 22:29:21 | 11445583810276646822 | 100 | FLEX | | 2023-07-27 23:10:06 | 7341455530498381779 | 100 | MONTHLY | | 2023-07-27 23:11:06 | 7341455530498381779 | -100 | MONTHLY | | 2023-07-27 23:11:06 | 7341455530498381779 | 100 | FLEX | */ capacity_commitment_slot_data AS ( SELECT change_timestamp, capacity_commitment_id, CASE WHEN action = "CREATE" OR action = "UPDATE" THEN IFNULL( IF( LAG(action) OVER ( PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC ) IN UNNEST(['CREATE', 'UPDATE']), slot_count - LAG(slot_count) OVER ( PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC ), slot_count), slot_count) ELSE IF( LAG(action) OVER (PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC) IN UNNEST(['CREATE', 'UPDATE']), -1 * slot_count, 0) END AS slot_count_delta, commitment_plan FROM capacity_changes_with_additional_deleted_event_for_changed_plan WHERE state = "ACTIVE" AND edition = edition_to_check AND change_timestamp <= end_time ), /* The total_committed_slots history for each plan. For example: +---------------------+---------------+-----------------+ | change_timestamp | capacity_slot | commitment_plan | +---------------------+---------------+-----------------+ | 2023-07-20 19:30:27 | 100 | ANNUAL | | 2023-07-27 22:29:21 | 100 | FLEX | | 2023-07-27 23:10:06 | 100 | MONTHLY | | 2023-07-27 23:11:06 | 0 | MONTHLY | | 2023-07-27 23:11:06 | 200 | FLEX | */ running_capacity_commitment_slot_data AS ( SELECT change_timestamp, SUM(slot_count_delta) OVER ( PARTITION BY commitment_plan ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS capacity_slot, commitment_plan, FROM capacity_commitment_slot_data ), /* The slot_seconds between each changes, partitioned by each plan. For example: +---------------------+--------------+-----------------+ | change_timestamp | slot_seconds | commitment_plan | +---------------------+--------------+-----------------+ | 2023-07-20 19:30:27 | 64617300 | ANNUAL | | 2023-07-27 22:29:21 | 250500 | FLEX | | 2023-07-27 23:10:06 | 6000 | MONTHLY | | 2023-07-27 23:11:06 | 0 | MONTHLY | | 2023-07-27 23:11:06 | 5626800 | FLEX | */ slot_seconds_data AS ( SELECT change_timestamp, GetSlotSecondsBetweenChanges( capacity_slot, UNIX_MILLIS(change_timestamp), UNIX_MILLIS( IFNULL( LEAD(change_timestamp) OVER (PARTITION BY commitment_plan ORDER BY change_timestamp ASC), CURRENT_TIMESTAMP())), UNIX_MILLIS(start_time), UNIX_MILLIS(end_time)) AS slot_seconds, commitment_plan, FROM running_capacity_commitment_slot_data WHERE change_timestamp <= end_time ) /* The final result is similar to the following: +-----------------+--------------------+ | commitment_plan | total_slot_seconds | +-----------------+--------------------+ | ANNUAL | 64617300 | | MONTHLY | 6000 | | FLEX | 5877300 | */ SELECT commitment_plan, SUM(slot_seconds) AS total_slot_seconds FROM slot_seconds_data GROUP BY commitment_plan
Le script suivant vérifie l'utilisation des emplacements qui n'est couverte par aucun engagement, pour une édition spécifique. Cette utilisation englobe deux types d'emplacements : les emplacements soumis à autoscaling et les emplacements de base, qui ne sont couverts par aucun engagement.
Développer pour afficher le script correspondant aux scénarios sans couverture par un engagement
/* This script has several parts: 1. Calculate the baseline and scaled slots for reservations 2. Calculate the committed slots 3. Join the two results above to calculate the baseline not covered by committed slots 4. Aggregate the number */ -- variables DECLARE start_time, end_time TIMESTAMP; DECLARE edition_to_check STRING; /* Google uses Pacific Time to calculate the billing period for all customers, regardless of their time zone. Use the following format if you want to match the billing report. Change the start_time and end_time values to match the desired window. */ /* The following three variables (start_time, end_time, and edition_to_check) are the only variables that you need to set in the script. During daylight savings time, the start_time and end_time variables should follow this format: 2024-02-20 00:00:00-08. */ SET start_time = "2023-07-20 00:00:00-07"; SET end_time = "2023-07-28 00:00:00-07"; SET edition_to_check = 'ENTERPRISE'; /* The following function returns the slot seconds for the time window between two capacity changes. For example, if there are 100 slots between (2023-06-01 10:00:00, 2023-06-01 11:00:00), then during that window the total slot seconds will be 100 * 3600. This script calculates a specific window (based on the variables defined above), which is why the following script includes script_start_timestamp_unix_millis and script_end_timestamp_unix_millis. */ CREATE TEMP FUNCTION GetSlotSecondsBetweenChanges( slots FLOAT64, range_begin_timestamp_unix_millis FLOAT64, range_end_timestamp_unix_millis FLOAT64, script_start_timestamp_unix_millis FLOAT64, script_end_timestamp_unix_millis FLOAT64) RETURNS INT64 LANGUAGE js AS r""" if (script_end_timestamp_unix_millis < range_begin_timestamp_unix_millis || script_start_timestamp_unix_millis > range_end_timestamp_unix_millis) { return 0; } var begin = Math.max(script_start_timestamp_unix_millis, range_begin_timestamp_unix_millis) var end = Math.min(script_end_timestamp_unix_millis, range_end_timestamp_unix_millis) return slots * Math.ceil((end - begin) / 1000.0) """; /* Sample RESERVATION_CHANGES data (unrelated columns ignored): +---------------------+------------------+--------+---------------+---------------+ | change_timestamp | reservation_name | action | slot_capacity | current_slots | +---------------------+------------------+--------+---------------+---------------+ | 2023-07-27 22:24:15 | res1 | CREATE | 300 | 0 | | 2023-07-27 22:25:21 | res1 | UPDATE | 300 | 180 | | 2023-07-27 22:39:14 | res1 | UPDATE | 300 | 100 | | 2023-07-27 22:40:20 | res2 | CREATE | 300 | 0 | | 2023-07-27 22:54:18 | res2 | UPDATE | 300 | 120 | | 2023-07-27 22:55:23 | res1 | UPDATE | 300 | 0 | Sample CAPACITY_COMMITMENT_CHANGES data (unrelated columns ignored): +---------------------+------------------------+-----------------+--------+------------+--------+ | change_timestamp | capacity_commitment_id | commitment_plan | state | slot_count | action | +---------------------+------------------------+-----------------+--------+------------+--------+ | 2023-07-20 19:30:27 | 12954109101902401697 | ANNUAL | ACTIVE | 100 | CREATE | | 2023-07-27 22:29:21 | 11445583810276646822 | FLEX | ACTIVE | 100 | CREATE | | 2023-07-27 23:10:06 | 7341455530498381779 | MONTHLY | ACTIVE | 100 | CREATE | */ WITH /* The scaled_slots & baseline change history: +---------------------+------------------+------------------------------+---------------------+ | change_timestamp | reservation_name | autoscale_current_slot_delta | baseline_slot_delta | +---------------------+------------------+------------------------------+---------------------+ | 2023-07-27 22:24:15 | res1 | 0 | 300 | | 2023-07-27 22:25:21 | res1 | 180 | 0 | | 2023-07-27 22:39:14 | res1 | -80 | 0 | | 2023-07-27 22:40:20 | res2 | 0 | 300 | | 2023-07-27 22:54:18 | res2 | 120 | 0 | | 2023-07-27 22:55:23 | res1 | -100 | 0 | */ reservation_slot_data AS ( SELECT change_timestamp, reservation_name, CASE action WHEN "CREATE" THEN autoscale.current_slots WHEN "UPDATE" THEN IFNULL( autoscale.current_slots - LAG(autoscale.current_slots) OVER ( PARTITION BY project_id, reservation_name ORDER BY change_timestamp ASC, action ASC ), IFNULL( autoscale.current_slots, IFNULL( -1 * LAG(autoscale.current_slots) OVER ( PARTITION BY project_id, reservation_name ORDER BY change_timestamp ASC, action ASC ), 0))) WHEN "DELETE" THEN IF( LAG(action) OVER ( PARTITION BY project_id, reservation_name ORDER BY change_timestamp ASC, action ASC ) IN UNNEST(['CREATE', 'UPDATE']), -1 * autoscale.current_slots, 0) END AS autoscale_current_slot_delta, CASE action WHEN "CREATE" THEN slot_capacity WHEN "UPDATE" THEN IFNULL( slot_capacity - LAG(slot_capacity) OVER ( PARTITION BY project_id, reservation_name ORDER BY change_timestamp ASC, action ASC ), IFNULL( slot_capacity, IFNULL( -1 * LAG(slot_capacity) OVER ( PARTITION BY project_id, reservation_name ORDER BY change_timestamp ASC, action ASC ), 0))) WHEN "DELETE" THEN IF( LAG(action) OVER ( PARTITION BY project_id, reservation_name ORDER BY change_timestamp ASC, action ASC ) IN UNNEST(['CREATE', 'UPDATE']), -1 * slot_capacity, 0) END AS baseline_slot_delta, FROM `region-us.INFORMATION_SCHEMA.RESERVATION_CHANGES` WHERE edition = edition_to_check AND change_timestamp <= end_time ), -- Convert the above to running total /* +---------------------+-------------------------+----------------+ | change_timestamp | autoscale_current_slots | baseline_slots | +---------------------+-------------------------+----------------+ | 2023-07-27 22:24:15 | 0 | 300 | | 2023-07-27 22:25:21 | 180 | 300 | | 2023-07-27 22:39:14 | 100 | 300 | | 2023-07-27 22:40:20 | 100 | 600 | | 2023-07-27 22:54:18 | 220 | 600 | | 2023-07-27 22:55:23 | 120 | 600 | */ running_reservation_slot_data AS ( SELECT change_timestamp, SUM(autoscale_current_slot_delta) OVER (ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS autoscale_current_slots, SUM(baseline_slot_delta) OVER (ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS baseline_slots, FROM reservation_slot_data ), /* The committed_slots change history. For example: +---------------------+------------------------+------------------+ | change_timestamp | capacity_commitment_id | slot_count_delta | +---------------------+------------------------+------------------+ | 2023-07-20 19:30:27 | 12954109101902401697 | 100 | | 2023-07-27 22:29:21 | 11445583810276646822 | 100 | | 2023-07-27 23:10:06 | 7341455530498381779 | 100 | */ capacity_commitment_slot_data AS ( SELECT change_timestamp, capacity_commitment_id, CASE WHEN action = "CREATE" OR action = "UPDATE" THEN IFNULL( IF( LAG(action) OVER ( PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC ) IN UNNEST(['CREATE', 'UPDATE']), slot_count - LAG(slot_count) OVER ( PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC ), slot_count), slot_count) ELSE IF( LAG(action) OVER (PARTITION BY capacity_commitment_id ORDER BY change_timestamp ASC, action ASC) IN UNNEST(['CREATE', 'UPDATE']), -1 * slot_count, 0) END AS slot_count_delta FROM `region-us.INFORMATION_SCHEMA.CAPACITY_COMMITMENT_CHANGES_BY_PROJECT` WHERE state = "ACTIVE" AND edition = edition_to_check AND change_timestamp <= end_time ), /* The total_committed_slots history. For example: +---------------------+---------------+ | change_timestamp | capacity_slot | +---------------------+---------------+ | 2023-07-20 19:30:27 | 100 | | 2023-07-27 22:29:21 | 200 | | 2023-07-27 23:10:06 | 300 | */ running_capacity_commitment_slot_data AS ( SELECT change_timestamp, SUM(slot_count_delta) OVER (ORDER BY change_timestamp RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS capacity_slot FROM capacity_commitment_slot_data ), /* Add next_change_timestamp to the above data, which will be used when joining with reservation data. For example: +---------------------+-----------------------+---------------+ | change_timestamp | next_change_timestamp | capacity_slot | +---------------------+-----------------------+---------------+ | 2023-07-20 19:30:27 | 2023-07-27 22:29:21 | 100 | | 2023-07-27 22:29:21 | 2023-07-27 23:10:06 | 200 | | 2023-07-27 23:10:06 | 2023-07-31 00:14:37 | 300 | */ running_capacity_commitment_slot_data_with_next_change AS ( SELECT change_timestamp, IFNULL(LEAD(change_timestamp) OVER (ORDER BY change_timestamp ASC), CURRENT_TIMESTAMP()) AS next_change_timestamp, capacity_slot FROM running_capacity_commitment_slot_data ), /* Whenever we have a change in reservations or commitments, the scaled_slots_and_baseline_not_covered_by_commitments will be changed. Hence we get a collection of all the change_timestamp from both tables. +---------------------+ | change_timestamp | +---------------------+ | 2023-07-20 19:30:27 | | 2023-07-27 22:24:15 | | 2023-07-27 22:25:21 | | 2023-07-27 22:29:21 | | 2023-07-27 22:39:14 | | 2023-07-27 22:40:20 | | 2023-07-27 22:54:18 | | 2023-07-27 22:55:23 | | 2023-07-27 23:10:06 | */ merged_timestamp AS ( SELECT change_timestamp FROM running_reservation_slot_data UNION DISTINCT SELECT change_timestamp FROM running_capacity_commitment_slot_data ), /* Change running reservation-slots and make sure we have one row when commitment changes. +---------------------+-------------------------+----------------+ | change_timestamp | autoscale_current_slots | baseline_slots | +---------------------+-------------------------+----------------+ | 2023-07-20 19:30:27 | 0 | 0 | | 2023-07-27 22:24:15 | 0 | 300 | | 2023-07-27 22:25:21 | 180 | 300 | | 2023-07-27 22:29:21 | 180 | 300 | | 2023-07-27 22:39:14 | 100 | 300 | | 2023-07-27 22:40:20 | 100 | 600 | | 2023-07-27 22:54:18 | 220 | 600 | | 2023-07-27 22:55:23 | 120 | 600 | | 2023-07-27 23:10:06 | 120 | 600 | */ running_reservation_slot_data_with_merged_timestamp AS ( SELECT change_timestamp, IFNULL( autoscale_current_slots, IFNULL( LAST_VALUE(autoscale_current_slots IGNORE NULLS) OVER (ORDER BY change_timestamp ASC), 0)) AS autoscale_current_slots, IFNULL( baseline_slots, IFNULL(LAST_VALUE(baseline_slots IGNORE NULLS) OVER (ORDER BY change_timestamp ASC), 0)) AS baseline_slots FROM running_reservation_slot_data RIGHT JOIN merged_timestamp USING (change_timestamp) ), /* Join the above, so that we will know the number for baseline not covered by commitments. +---------------------+-----------------------+-------------------------+------------------------------------+ | change_timestamp | next_change_timestamp | autoscale_current_slots | baseline_not_covered_by_commitment | +---------------------+-----------------------+-------------------------+------------------------------------+ | 2023-07-20 19:30:27 | 2023-07-27 22:24:15 | 0 | 0 | | 2023-07-27 22:24:15 | 2023-07-27 22:25:21 | 0 | 200 | | 2023-07-27 22:25:21 | 2023-07-27 22:29:21 | 180 | 200 | | 2023-07-27 22:29:21 | 2023-07-27 22:39:14 | 180 | 100 | | 2023-07-27 22:39:14 | 2023-07-27 22:40:20 | 100 | 100 | | 2023-07-27 22:40:20 | 2023-07-27 22:54:18 | 100 | 400 | | 2023-07-27 22:54:18 | 2023-07-27 22:55:23 | 220 | 400 | | 2023-07-27 22:55:23 | 2023-07-27 23:10:06 | 120 | 400 | | 2023-07-27 23:10:06 | 2023-07-31 00:16:07 | 120 | 300 | */ scaled_slots_and_baseline_not_covered_by_commitments AS ( SELECT r.change_timestamp, IFNULL(LEAD(r.change_timestamp) OVER (ORDER BY r.change_timestamp ASC), CURRENT_TIMESTAMP()) AS next_change_timestamp, r.autoscale_current_slots, IF( r.baseline_slots - IFNULL(c.capacity_slot, 0) > 0, r.baseline_slots - IFNULL(c.capacity_slot, 0), 0) AS baseline_not_covered_by_commitment FROM running_reservation_slot_data_with_merged_timestamp r LEFT JOIN running_capacity_commitment_slot_data_with_next_change c ON r.change_timestamp >= c.change_timestamp AND r.change_timestamp < c.next_change_timestamp ), /* The slot_seconds between each changes. For example: +---------------------+--------------------+ | change_timestamp | slot_seconds | +---------------------+--------------+ | 2023-07-20 19:30:27 | 0 | | 2023-07-27 22:24:15 | 13400 | | 2023-07-27 22:25:21 | 91580 | | 2023-07-27 22:29:21 | 166320 | | 2023-07-27 22:39:14 | 13200 | | 2023-07-27 22:40:20 | 419500 | | 2023-07-27 22:54:18 | 40920 | | 2023-07-27 22:55:23 | 459160 | | 2023-07-27 23:10:06 | 11841480 | */ slot_seconds_data AS ( SELECT change_timestamp, GetSlotSecondsBetweenChanges( autoscale_current_slots + baseline_not_covered_by_commitment, UNIX_MILLIS(change_timestamp), UNIX_MILLIS(next_change_timestamp), UNIX_MILLIS(start_time), UNIX_MILLIS(end_time)) AS slot_seconds FROM scaled_slots_and_baseline_not_covered_by_commitments WHERE change_timestamp <= end_time AND next_change_timestamp > start_time ) /* Final result for this example: +--------------------+ | total_slot_seconds | +--------------------+ | 13045560 | */ SELECT SUM(slot_seconds) AS total_slot_seconds FROM slot_seconds_data
Surveiller les performances des tâches
Vous devrez peut-être ajuster votre max_slots d'autoscaling pour éviter des coûts plus élevés. La requête suivante fournit un contexte sur les performances de votre tâche afin que vous puissiez choisir le nombre approprié d'emplacements d'autoscaling pour votre charge de travail.
La requête suivante fournit des détails sur les performances de vos réservations :
SELECT AVG(TIMESTAMP_DIFF(end_time, creation_time, MILLISECOND)) as avg_latency_ms, COUNT(*) as query_numbers, FROM `PROJECT_ID.region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION WHERE creation_time >= START_TIME AND creation_time < END_TIME AND (statement_type != "SCRIPT" OR statement_type IS NULL) AND reservation_id = RESERVATION_ID
Remplacez les éléments suivants :
PROJECT_ID: ID du projetREGION_NAME: région de votre projetSTART_TIME: heure de création à laquelle vous souhaitez commencer à afficher les données.END_TIME: heure de création à laquelle vous souhaitez arrêter d'afficher les données.RESERVATION_ID: ID de la réservation.
L'exemple suivant obtient les détails de la tâche sur une période de cinq jours :
SELECT AVG(TIMESTAMP_DIFF(end_time, creation_time, MILLISECOND)) as avg_latency_ms, COUNT(*) as query_numbers, FROM `myproject.region-us`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATION WHERE creation_time >= '2024-06-25 00:00:00-07' AND creation_time < '2024-06-30 00:00:00-07' AND (statement_type != "SCRIPT" OR statement_type IS NULL) AND reservation_id = reservationID
Quotas
La somme de votre taille de réservation maximale ne doit pas dépasser votre quota d'emplacements.
Pour en savoir plus sur les quotas, consultez la section Quotas et limites.
Étapes suivantes
- Pour en savoir plus sur les éditions BigQuery, consultez la page Présentation de BigQuery.
- Pour en savoir plus sur les emplacements, consultez la section Comprendre les emplacements.
- Pour en savoir plus sur les réservations, consultez la section Présentation des réservations.