Noções básicas sobre os slots

Um slot do BigQuery é uma unidade de computação virtual usada pelo BigQuery para executar consultas SQL, código Python ou outros tipos de job. Durante a execução de uma consulta, o BigQuery determina automaticamente quantos slots são usados por ela. O número de slots usados depende da quantidade de dados processados, da complexidade da consulta e do número de slots disponíveis. Em geral, o acesso a mais slots permite executar mais consultas simultâneas e consultas complexas podem ser executadas mais rapidamente.

Preços on demand e baseados em capacidade

Embora todas as consultas usem slots, você tem duas opções de cobrança pelo uso: o modelo de preços on demand ou o modelo de preços com base na capacidade.

Por padrão, a cobrança é feita usando o modelo on demand. Com esse modelo, você recebe cobranças pela quantidade de dados processados (medidos em TiB) por cada consulta. Os projetos que usam o modelo on demand estão sujeitos a limites de slots por projeto e por organização com capacidade de burst temporário. A maioria dos usuários no modelo on demand considera os limites de capacidade de slot mais do que suficientes. No entanto, dependendo da sua carga de trabalho, o acesso a mais slots pode melhorar o desempenho da consulta. Para verificar o uso de slots da sua conta, consulte Monitorar a integridade, a utilização de recursos e os jobs.

Com o modelo baseado em capacidade, você paga pela capacidade de slot alocada para suas consultas ao longo do tempo. Esse modelo oferece controle explícito sobre a capacidade total de slots. Você escolhe explicitamente a quantidade de slots a serem usados por uma reserva. É possível especificar o número de slots em uma reserva como um valor de referência, que é sempre alocado, ou como um valor de escalonamento automático, que é alocado quando necessário. As reservas com slots de escalonamento automático escalonam a capacidade para acomodar as demandas de carga de trabalho. O BigQuery aloca slots à medida que as cargas de trabalho mudam. Isso permite configurar o número de slots em uma reserva com base no desempenho ou na natureza crítica da carga de trabalho que usa a reserva.

Execução de consultas usando slots

Quando o BigQuery executa um job de consulta, ele converte a instrução SQL em um plano de execução, composto por uma série de estágios de consulta. Os estágios, por sua vez, são compostos por conjuntos de etapas de execução. O BigQuery usa uma arquitetura paralela distribuída para executar consultas. Os estágios modelam as unidades de trabalho que podem ser executadas em paralelo. Os dados são transmitidos entre estágios usando uma arquitetura de embaralhamento distribuída, que é discutida em mais detalhes nesta postagem do blogGoogle Cloud .

A execução de consultas do BigQuery é dinâmica. Um plano de consulta pode ser modificado enquanto a consulta está sendo processada. A distribuição do trabalho pode ser otimizada para a distribuição de dados à medida que as etapas são adicionadas. Além disso, a capacidade de execução de uma consulta pode mudar à medida que outras consultas são iniciadas ou concluídas, ou quando o escalonador automático adiciona slots a uma reserva.

O BigQuery pode executar vários estágios simultaneamente, usar a execução especulativa para acelerar uma consulta e reparticionar dinamicamente um estágio para atingir o carregamento em paralelo ideal.

Economia de recursos de slot

Se uma consulta solicitar mais slots do que o número disponível, o BigQuery coloca unidades de trabalho individuais em fila e espera que os slots fiquem disponíveis. Conforme a execução da consulta avança e libera slots, as unidades de trabalho com filas são selecionadas para execução.

O BigQuery pode solicitar qualquer número de slots para um cenário específico de uma consulta. O número de slots solicitados não está relacionado à quantidade de capacidade adquirida. Ele indica o fator de carregamento em paralelo ideal escolhido pelo BigQuery para cada cenário. As unidades de trabalho são colocadas em fila e executadas conforme os slots ficam disponíveis.

Quando as demandas de consulta excederem os slots confirmados, você não será cobrado por slots adicionais e nem serão cobradas taxas adicionais sob demanda. Suas unidades de trabalho individuais serão enfileiradas.

Por exemplo,

1. Um cenário de consulta solicita 2.000 slots, mas há apenas 1.000 disponíveis.
2. O BigQuery consome todos os 1.000 slots e coloca os outros 1.000 em fila.
3. Na sequência, quando 100 slots terminarem o trabalho, eles selecionarão dinamicamente 100 unidades de trabalho entre as 1.000 unidades de trabalho na fila. 900 unidades de trabalho permanecerão na fila.
4. Posteriormente, quando 500 slots terminarem o trabalho, eles selecionarão dinamicamente 500 unidades de trabalho entre as 900 unidades de trabalho na fila. 400 unidades de trabalho permanecerão na fila.

Os slots do BigQuery são enfileirados quando a demanda excede a disponibilidade

Se a carga de trabalho exigir mais slots do que os disponíveis para a reserva, o tempo de execução do job poderá aumentar à medida que os jobs aguardam a disponibilidade de slots. Isso é conhecido como disputa de slots. A disputa de slots pode aumentar se a demanda da carga de trabalho for muito maior do que os slots disponíveis para a reserva.

Priorização de capacidade

Quando o BigQuery tem alta demanda por recursos de slot em uma região específica, ele gerencia a disputa priorizando a capacidade. Essa priorização garante que os clientes com modelos de capacidade de nível superior sejam menos afetados. O sistema prioriza a capacidade na seguinte ordem:

1. Capacidade comprometida e níveis de referência das edições Enterprise Plus e Enterprise.
2. Capacidade com escalonamento automático do Enterprise Plus.
3. Capacidade de escalonamento automático da edição Enterprise.
4. Edição Standard e capacidade on demand.

Em caso de disputa em uma região, é mais provável que a edição Standard e as solicitações de capacidade on demand tenham atrasos no acesso, porque o sistema aloca recursos primeiro para edições de nível superior.

Programação equitativa no BigQuery

O BigQuery aloca capacidade de slot em uma única reserva usando um algoritmo chamado programação regular.

O programador do BigQuery impõe o compartilhamento igualitário de slots entre projetos com consultas em execução em uma reserva e, em seguida, nos jobs de um determinado projeto. O programador fornece uma igualdade eventual. Durante períodos curtos, alguns jobs podem receber uma parcela desproporcional de slots, mas o programador corrige isso depois. O objetivo do programador é encontrar um equilíbrio entre a remoção agressiva de tarefas em execução (o que resulta em desperdício de tempo de slot) e ser muito tolerante (o que resulta em jobs com tarefas de longa duração recebendo uma parcela desproporcional o horário do slot).

A programação justa garante que cada consulta tenha acesso a todos os slots disponíveis a qualquer momento, e a capacidade é realocada de maneira dinâmica e automática entre as consultas ativas à medida que as demandas de capacidade de cada consulta mudam. As consultas são concluídas e novas consultas são enviadas para execução sob as seguintes condições:

• Sempre que uma nova consulta é enviada, a capacidade é automaticamente realocada entre as consultas em execução. As unidades de trabalho individuais podem ser pausadas, retomadas e enfileiradas sem incidentes à medida que a capacidade disponível aumenta para cada consulta.
• Sempre que uma consulta é concluída, a capacidade consumida por essa consulta fica automaticamente disponível para o uso de todas as outras.
• Sempre que as demandas de capacidade de uma consulta mudam devido a alterações no DAG dinâmico dela, o BigQuery reavalia automaticamente a disponibilidade de capacidade para essa e todas as outras consultas, realocando e pausando os slots conforme necessário.

Programação equitativa no BigQuery

Dependendo da complexidade e do tamanho, uma consulta pode não demandar todos os slots aos quais ela tem direito ou pode exigir mais. Com esse tipo de programação, o BigQuery garante, de modo dinâmico, que todos os slots sejam totalmente utilizados a qualquer momento.

Se um job importante precisar de mais slots de maneira consistente do que recebe do programador, procure criar uma reserva adicional com o número necessário de slots e atribuir o job a essa reserva.

Como exemplo de programação justa, suponha que você tenha a seguinte configuração de reserva:

• Reserva A, que tem 1.000 slots de valor de referência sem escalonamento automático
• Projetos A e B, que estão atribuídos à sua reserva

Cenário 1: no projeto A, você executa a consulta A (uma consulta simultânea) que exige alto uso de slots. No projeto B, você executa 20 consultas simultâneas. Embora haja um total de 21 consultas usando a reserva A, a distribuição de slots é a seguinte:

• O projeto A recebe 500 slots, e a consulta A é executada com 500 slots.
• O projeto B recebe 500 slots compartilhados entre as 20 consultas.

Cenário 2: no projeto A, você executa a consulta A (uma consulta simultânea) que requer 100 slots para ser executada, e no projeto B você executa 20 consultas simultâneas. Como a consulta A não exige 50% da reserva, a distribuição de slots é a seguinte:

• O projeto A recebe 100 slots, e a consulta A é executada com 100 slots.
• O projeto B recebe 900 slots compartilhados entre as 20 consultas.

Por outro lado, considere a seguinte configuração de reserva:

• Reserva B, que tem 1.000 slots de valor de referência sem escalonamento automático.
• 10 projetos, todos atribuídos à reserva B.

Suponha que os 10 projetos estejam executando consultas com demanda de slots suficiente. Cada projeto vai receber 1/10 do total de slots de reserva (ou 100 slots), independente de quantas consultas estejam sendo executadas em cada projeto.

Cotas e limites de slots

As cotas e os limites de slots fornecem uma proteção para o BigQuery. Diferentes modelos de preços usam diferentes tipos de cota de slot, como segue:

• Modelo de preços on demand: você está sujeito a um limite de slot por projeto e organização com capacidade de burst temporário. Dependendo das suas cargas de trabalho, o acesso a mais slots pode melhorar o desempenho da consulta.

• Modelo de preços baseado em capacidade: as cotas e limites de reserva definem o número máximo de slots que podem ser distribuídos em todas as reservas em um local. Se você usar o escalonamento automático, a soma dos tamanhos máximos de reserva não poderá exceder esse limite. Você só é cobrado por suas reservas e compromissos, não pelas cotas. Para mais informações sobre como aumentar a cota de slots, consulte Como solicitar um aumento de cota.

Para verificar quantos slots você está usando, consulte Monitoramento do BigQuery.

Slots inativos

É possível que alguns slots fiquem inativos a qualquer momento. Isso inclui:

• Compromissos de slots que não estão alocados para nenhum valor de referência.
• Slots que estão alocados para um valor de referência de reserva, mas não estão em uso no momento.

Os slots inativos não são relevantes ao usar o modelo de preços on demand.

Por padrão, as consultas em execução em uma reserva usam automaticamente slots inativos de outras reservas na mesma região e projeto de administração. O BigQuery aloca imediatamente slots inativos para uma reserva atribuída quando eles são necessários. Os slots inativos que estavam em uso por outra reserva são rapidamente substituídos, se necessário, pela reserva original. Pode haver um curto período em que o consumo total de slots exceda o máximo especificado em todas as reservas, mas você não vai receber cobranças por esse uso adicional.

Por exemplo, suponha que você tenha a seguinte configuração de reserva:

• project_a é atribuído a reservation_a, que tem 500 slots de valor de referência sem escalonamento automático.
• project_b é atribuído a reservation_b, que tem 100 slots de valor de referência sem escalonamento automático.
• As duas reservas estão na mesma região e projeto administrativo, e não há outros projetos atribuídos a elas.

Você executa query_b em project_b. Se nenhuma consulta estiver em execução em project_a, query_b terá acesso aos 500 slots inativos de reservation_a. Enquanto query_b ainda estiver em execução, ele poderá usar até 600 slots: 100 slots de valor de referência mais 500 slots ociosos.

Enquanto query_b está em execução, suponha que você execute query_a em project_a, que pode usar 500 slots.

• Como você tem 500 slots de valor de referência reservados para project_a, query_a começa imediatamente e recebe 500 slots.
• O número de slots alocados para query_b diminui rapidamente para 100 slots de valor de referência.
• Outras consultas executadas em project_b compartilham esses 100 slots. Se as consultas subsequentes não tiverem slots suficientes para serem iniciadas, elas serão enfileiradas até que as consultas em execução sejam concluídas e os slots fiquem disponíveis.

Neste exemplo, se project_b fosse atribuído a uma reserva sem slots de valor de referência ou escalonamento automático, query_b não teria slots depois que query_a começasse a ser executado. O BigQuery pausava query_b até que slots inativos estivessem disponíveis ou a consulta expirasse. Outras consultas em project_b seriam enfileiradas até que slots inativos ficassem disponíveis.

Para garantir que uma reserva use apenas os slots provisionados, defina ignore_idle_slots como true. No entanto, as reservas com ignore_idle_slots definido como true podem compartilhar os slots inativos com outras reservas.

Não é possível compartilhar slots inativos entre as reservas de diferentes edições. É possível compartilhar somente os slots de valor de referência ou slots confirmados. Os slots com escalonamento automático podem estar temporariamente disponíveis, mas não podem ser compartilhados como slots inativos para outras reservas porque podem ser reduzidos.

Enquanto ignore_idle_slots for falso, uma reserva poderá ter uma contagem de slots de 0 e ainda ter acesso a slots não utilizados. Se você usar apenas a reserva default, desative ignore_idle_slots como prática recomendada. Em seguida, é possível atribuir um projeto ou uma pasta a essa reserva, e ela usará apenas slots inativos.

As atribuições do tipo ML_EXTERNAL são uma exceção nos slots usados pelos jobs de criação de modelos externos do BigQuery ML não são preemptivas. Os slots em uma reserva com os tipos de atribuição ML_EXTERNAL e QUERY só estão disponíveis para outros jobs de consulta quando os slots não são ocupados pelos jobs ML_EXTERNAL. Além disso, esses jobs não podem usar slots inativos de outras reservas.

Justiça com base em reserva

Observação: é necessário ativar a equidade baseada em reservas antes de criar uma reserva previsível.

Com a justiça baseada em reserva, o BigQuery prioriza e aloca slots inativos igualmente em todas as reservas no mesmo projeto administrador, independente do número de projetos que executam jobs em cada reserva. Cada reserva recebe uma parte semelhante da capacidade disponível no pool de slots ociosos, e depois os slots são distribuídos de forma justa entre os projetos. Esse recurso só é compatível com as edições Enterprise ou Enterprise Plus.

O gráfico a seguir mostra como os slots ociosos são distribuídos sem a ativação da justiça baseada em reserva:

Neste gráfico, os slots inativos são compartilhados igualmente entre os projetos.

Sem a ativação da justiça baseada em reserva, os slots ociosos disponíveis são distribuídos uniformemente entre os projetos nas reservas.

O gráfico a seguir mostra como os slots ociosos são distribuídos com a justiça baseada em reserva ativada:

Neste gráfico, os slots inativos são compartilhados igualmente entre as reservas, não entre os projetos.

Com a imparcialidade baseada em reserva ativada, os slots ociosos disponíveis são distribuídos igualmente entre as reservas.

Ao ativar a justiça baseada em reserva, analise o consumo de recursos para gerenciar a disponibilidade de slots e o desempenho das consultas.

Evite depender apenas de slots ociosos para cargas de trabalho de produção com requisitos de tempo estritos. Esses jobs precisam usar slots de valor de referência ou com escalonamento automático. Recomendamos usar slots ociosos para jobs de prioridade mais baixa, porque eles podem ser interrompidos a qualquer momento.

Escalonamento automático de slots

A seção a seguir discute os slots de escalonamento automático e como eles funcionam com as reservas.

Usar reservas de escalonamento automático

Você não precisa adquirir compromissos de slot antes de criar reservas de escalonamento automático. Os compromissos de slot fornecem um preço com desconto para slots usados de forma consistente, mas são opcionais com reservas de escalonamento automático. Para criar uma reserva de escalonamento automático, atribua uma reserva a um número máximo de slots (o tamanho máximo da reserva). Para identificar o número máximo de slots de escalonamento automático, subtraia o tamanho máximo da reserva de todos os slots de valor de referência opcionais atribuídos à reserva.

Ao criar reservas de escalonamento automático, considere o seguinte:

• O BigQuery escalona reservas quase instantaneamente até atingir o número de slots necessários para executar os jobs ou atingir o número máximo de slots disponíveis para a reserva. Os slots sempre são escalonados automaticamente para um múltiplo de 50.
• O escalonamento vertical é baseado no uso real e arredondado para o incremento de 50 slots mais próximo.
• Os slots com escalonamento automático são cobrados de acordo com os preços de capacidade de computação da edição associada durante o escalonamento vertical. Você é cobrado pelo número de slots escalonados, não pelo número de slots usados. Essa cobrança será aplicada mesmo se o job que faz o BigQuery escalonar verticalmente falhar. Por isso, não use o esquema de informações de jobs para corresponder ao faturamento. Em vez disso, consulte Monitorar o escalonamento automático com esquema de informações.
• O número de slots sempre é escalonado por múltiplos de 50, mas é possível escalonar mais de 50 slots em uma etapa. Por exemplo, se sua carga de trabalho exigir mais 450 slots, o BigQuery pode tentar escalonar por 450 slots de uma vez para atender ao requisito de capacidade.
• O BigQuery reduz a escala quando os jobs associados à reserva não precisam mais da capacidade (sujeito a um mínimo de 1 minuto).

Toda capacidade de escalonamento automático é mantida por pelo menos 60 segundos. Esse período de 60 segundos é chamado de janela de redução. Qualquer novo pico na capacidade redefine a janela de redução, tratando todo o nível de capacidade como um novo benefício. No entanto, se 60 segundos ou mais tiverem se passado desde o último aumento de capacidade e houver menos demanda, o sistema vai reduzir a capacidade sem redefinir a janela de redução de escala, permitindo diminuições consecutivas sem um atraso imposto.

Por exemplo, se a capacidade inicial da carga de trabalho for dimensionada para 100 slots, o pico será mantido por pelo menos 60 segundos. Se, durante esse período, sua carga de trabalho for escalonada para um novo pico de 200 slots, um novo período de redução será iniciado por 60 segundos. Se não houver um novo pico durante essa janela de redução de escala, sua carga de trabalho começará a ser reduzir escala vertical no final dos 60 segundos.

Considere o exemplo detalhado a seguir: às 12:00:00, sua capacidade inicial é escalonada para 100 slots, e o uso dura um segundo. Esse pico é mantido por pelo menos 60 segundos, começando às 12:00:00. Após os 60 segundos (às 12:01:01), se o novo uso for de 50 slots, o BigQuery vai reduzir a escala para 50 slots. Se, às 12:01:02, o novo uso for de 0 slots, o BigQuery vai reduzir imediatamente para 0 slots. Depois que a janela de redução termina, o BigQuery pode reduzir escala vertical várias vezes consecutivas sem exigir uma nova janela.

Para saber como trabalhar com o escalonamento automático, consulte Trabalhar com slots de escalonamento automático.

Como usar reservas com slots de valor de referência e escalonamento automático

Além de especificar o tamanho máximo da reserva, é possível opcionalmente determinar um número de referência de slots por reserva. O valor de referência é o número mínimo de slots que sempre serão alocados na reserva e que sempre serão cobrados. Os slots de escalonamento automático são adicionados somente depois que todos os slots de linha de base (e os slots inativos, se aplicável) são consumidos. É possível compartilhar slots de valor de referência inativos em uma reserva com outras que precisam de capacidade.

É possível aumentar o número de slots de valor de referência em uma reserva a cada poucos minutos. Se você quiser diminuir os slots de valor de referência, terá o limite de uma hora por hora se tiver alterado recentemente a capacidade de slots do valor de referência e os slots de referência excederem os slots confirmados. Caso contrário, é possível diminuir os slots de valor de referência em intervalos de alguns minutos.

Os slots de valor de referência e de escalonamento automático foram projetados para fornecer capacidade com base na sua carga de trabalho recente. Se você antecipar uma grande carga de trabalho que seja muito diferente das suas cargas de trabalho recentes, recomendamos aumentar a capacidade de valor de referência antes do evento, em vez de depender de slots de escalonamento automático para cobrir a capacidade. Se você encontrar um problema ao aumentar a capacidade de valor de referência, tente novamente após 15 minutos.

Se a reserva não tiver slots de valor de referência ou não estiver configurada para emprestar slots inativos de outras reservas, o BigQuery tentará escalonar. Caso contrário, os slots de valor de referência precisam ser totalmente utilizados antes do escalonamento.

As reservas usam e adicionam slots na seguinte prioridade:

1. Slots de referência:
2. Compartilhamento de slots inativos (se ativado). As reservas só podem compartilhar valor de referência ocioso ou slots confirmados de outras reservas que foram criadas com a mesma edição e a mesma região.
3. Slots de escalonamento automático.

No exemplo a seguir, os slots são dimensionados de acordo com um valor de referência especificado. As reservas etl e dashboard têm um tamanho de referência de 700 e 300 slots, respectivamente.

Neste exemplo, a reserva etl pode ser dimensionada para 1.300 slots (700 slots de valor de referência mais 600 slots de escalonamento automático). Se a reserva dashboard não estiver em uso, a reserva etl poderá usar os 300 slots da reserva dashboard se nenhum job estiver em execução lá, levando a um máximo de 1.600 slots possíveis slots.

A reserva dashboard pode ser escalonada para 1.100 slots (300 slots de valor de referência mais 800 slots de escalonamento automático). Se a reserva etl estiver totalmente inativa, a reserva dashboard poderá ser escalonada para, no máximo, 1.800 slots (300 slots de valor de referência, 800 slots de escalonamento automático, mais 700 slots inativos na reserva etl).

Se a reserva etl exigir mais de 700 slots de valor de referência, que estão sempre disponíveis, ela tentará adicionar slots usando os seguintes métodos na ordem:

1. 700 slots de referência.
2. Compartilhamento de slot inativo com os 300 slots de valor de referência na reserva dashboard. Sua reserva compartilha apenas slots de linha de base inativos com outras reservas criadas com a mesma edição.
3. Escalonar verticalmente mais 600 slots para o tamanho máximo de reserva.

Como usar compromissos de slot

No exemplo a seguir, mostramos o escalonamento automático de slots usando compromissos de capacidade.

Assim como os valores de referência de reserva, os compromissos de slot permitem alocar um número fixo de slots disponíveis para todas as reservas. Ao contrário dos slots de valor de referência, não é possível reduzir um compromisso durante o prazo. Os compromissos de slot são opcionais, mas podem economizar custos se forem necessários slots de valor de referência por longos períodos. Os compromissos de slot são usados para cobrir slots de valor de referência para suas reservas. Qualquer capacidade de slot não utilizada é compartilhada como slots inativos em outras reservas. Os compromissos de slot não se aplicam a slots de escalonamento automático. Para garantir que você receba o preço com desconto para seus slots comprometidos, verifique se os compromissos de slot são suficientes para cobrir os slots de valor de referência.

Neste exemplo, é cobrada uma taxa predefinida pelos slots de compromisso de capacidade. Você será cobrado pela taxa de escalonamento automático pelo número de slots de escalonamento automático após a ativação do escalonamento automático e as reservas em um estado otimizado. Para a taxa de escalonamento automático, você é cobrado pelo número de slots escalonados, não pelo número de slots usados.

O exemplo a seguir mostra reservas quando o número de slots de valor de referência excede o número de slots confirmados.

Neste exemplo, há um total de 1.000 slots de valor de referência entre as duas reservas: 500 da reserva etl e 500 da reserva dashboard. No entanto, o compromisso abrange apenas 800 slots. Nesse cenário, os slots excedentes são cobrados de acordo com a taxa de pagamento conforme o uso (PAYG).

Máximo de slots disponíveis

É possível calcular o número máximo de slots que uma reserva pode usar adicionando os slots de valor de referência, o número máximo de slots de escalonamento automático e todos os slots em compromissos que foram criados com a mesma edição e não são cobertos pelos slots de valor de referência. O exemplo na imagem anterior é configurado da seguinte maneira:

• Um compromisso de capacidade de 1.000 slots anuais. Esses slots são atribuídos como slots de referência na reserva etl e na reserva dashboard.
• 700 slots de valor de referência atribuídos à reserva etl.
• 300 slots de valor de referência atribuídos à reserva dashboard.
• Escalonamento automático de slots de 600 para a reserva etl.
• Escalonamento automático de slots de 800 para a reserva dashboard.

Para a reserva etl, o número máximo de slots possível é igual aos slots de referência etl (700) mais os slots de valor de referência dashboard (300, se todos os slots estiverem inativos). mais o número máximo de slots de escalonamento automático (600). Portanto, o número máximo de slots que a reserva etl pode usar neste exemplo é 1.600. Esse número excede o do compromisso de capacidade.

No exemplo a seguir, o compromisso anual excede os slots de valor de referência atribuídos.

Neste exemplo, temos:

• Um compromisso de capacidade de 1.600 slots anuais.
• Um tamanho máximo de reserva de 1.500 (incluindo 500 slots de escalonamento automático).
• 1.000 slots de valor de referência atribuídos à reserva etl.

O número máximo de slots disponíveis para a reserva é igual aos slots de valor de referência (1.000), mais os slots inativos com compromisso não dedicados aos slots de valor de referência (1.600 slots anuais - 1.000 slots de valor de referência = 600) mais o número de slots de escalonamento automático (500). Portanto, o número máximo de slots possíveis nessa reserva é de 2.100. Os slots com escalonamento automático são slots adicionais acima do compromisso de capacidade.

Práticas recomendadas para escalonamento automático

1. Ao usar o escalonador automático pela primeira vez, defina o número de slots de escalonamento automático como um número significativo com base no desempenho anterior e esperado. Depois que a reserva for criada, monitore ativamente a taxa de falhas, o desempenho e o faturamento e ajuste o número de slots de escalonamento automático conforme necessário.

2. O escalonador automático tem um mínimo de 1 minuto antes de reduzir a escala. Por isso, é importante definir o número máximo de slots escalonados automaticamente para equilibrar desempenho e custo. Se o número máximo de slots de escalonamento automático for muito grande e seu job puder usar todos os slots para concluir um job em segundos, você ainda vai incorrer em custos pelos slots máximos durante o minuto inteiro. Se você reduzir o número máximo de slots para metade da quantidade atual, sua reserva será ajustada para um número menor, e o job poderá usar mais slot_seconds durante esse minuto, reduzindo o desperdício. Para determinar seus requisitos de slot, consulte Monitorar a performance do job. Como alternativa para determinar seus requisitos de slot, consulte Ver recomendações de slot da edição.

3. De vez em quando, o uso de slots pode exceder a soma do valor de referência mais os slots dimensionados. Você não vai receber cobranças pelo uso de slots maior que o valor de referência mais os slots escalonados.

4. O autoescalador é mais eficiente para cargas de trabalho pesadas e de longa duração, como cargas de trabalho com várias consultas simultâneas. Evite enviar consultas uma de cada vez, já que cada uma delas ajusta a reserva, que permanece ajustada por um minuto no mínimo. Se você enviar consultas continuamente, causando uma carga de trabalho constante, definir um valor de referência e comprar um compromisso fornecerá capacidade constante a um preço com desconto.

5. O escalonamento automático do BigQuery está sujeito à disponibilidade de capacidade. O BigQuery tenta atender à demanda de capacidade do cliente com base no uso histórico. Para alcançar as garantias de capacidade, defina um valor de referência de slot opcional, que é o número de slots garantidos em uma reserva. Com os valores de referência, os slots ficam disponíveis imediatamente e você paga por eles, independentemente de usá-los ou não. Para garantir que a capacidade esteja disponível para grandes demandas inorgânicas, como feriados de alto tráfego, entre em contato com a equipe do BigQuery com várias semanas de antecedência.

6. Os slots de valor de referência sempre são carregados. Se um compromisso de capacidade expirar, talvez seja necessário ajustar manualmente a quantidade de slots de valor de referência nas reservas para evitar cobranças indesejadas. Por exemplo, considere que você tem um compromisso de um ano com 100 slots e uma reserva com 100 slots de valor de referência. O compromisso expira e não tem um plano de renovação. Quando o compromisso expirar, você pagará por 100 slots de valor de referência com a taxa de pagamento por utilização.

Monitorar o escalonamento automático

Para informações sobre como monitorar o uso de slots e a performance de jobs com o escalonamento automático, consulte Monitorar o escalonamento automático.

Uso excessivo de slots

Quando um job retém slots por muito tempo, ele pode receber uma parcela injusta de slots. Para evitar atrasos, o BigQuery permite que outros jobs peguem emprestado slots adicionais, resultando em períodos de uso total de slots acima da capacidade especificada. Qualquer uso excessivo de slots é atribuído apenas aos jobs que recebem mais do que a parte justa.

Os slots excedentes não são cobrados diretamente de você. Em vez disso, os jobs continuam sendo executados e acumulando o uso de slots na proporção adequada até que todo o uso em excesso seja coberto pela capacidade alocada. Os slots excedentes são excluídos do uso de slots informado, exceto algumas estatísticas detalhadas de execução.

Vale lembrar que alguns empréstimos preventivos de slots podem ocorrer para reduzir atrasos futuros e oferecer outros benefícios, como variabilidade de custo de slot e latência de cauda reduzidas. O empréstimo de slots é limitado a uma pequena fração da capacidade total de slots.