Compreenda os espaços

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

Preços a pedido e com base na capacidade

Embora todas as consultas usem espaços, tem duas opções para a forma como lhe é cobrado o uso: o modelo de preços a pedido ou o modelo de preços baseado na capacidade.

Por predefinição, os custos são cobrados através do modelo a pedido. Com este modelo, é-lhe cobrado o valor dos dados processados (medidos em TiB) por cada consulta. Os projetos que usam o modelo a pedido estão sujeitos a limites de slots por projeto e por organização com capacidade de picos transitórios. A maioria dos utilizadores no modelo a pedido considera os limites de capacidade dos espaços mais do que suficientes. No entanto, consoante a sua carga de trabalho, o acesso a mais espaços pode melhorar o desempenho das consultas. Para verificar a utilização de slots da sua conta, consulte o artigo Monitorize o estado, a utilização de recursos e as tarefas.

Com o modelo baseado na capacidade, paga pela capacidade de slots atribuída às suas consultas ao longo do tempo. Este modelo dá-lhe controlo explícito sobre a capacidade total de espaços. Escolhe explicitamente a quantidade de ranhuras a usar através de uma reserva. Pode especificar o número de espaços numa reserva como um valor de base que é sempre atribuído ou como um valor de dimensionamento automático que é atribuído quando necessário. As reservas com intervalos de dimensionamento automático dimensionam a respetiva capacidade para dar resposta às exigências da sua carga de trabalho. O BigQuery atribui slots à medida que as cargas de trabalho mudam. Isto permite-lhe configurar o número de espaços numa reserva com base no desempenho ou na natureza crítica da carga de trabalho que usa a reserva.

Execução de consultas através de espaços

Quando o BigQuery executa uma tarefa de consulta, converte a declaração SQL num plano de execução, composto por uma série de fases de consulta. Por sua vez, as fases são compostas por conjuntos de passos de execução. O BigQuery usa uma arquitetura paralela distribuída para executar consultas. As fases modelam as unidades de trabalho que podem ser executadas em paralelo. Os dados são transmitidos entre as fases através de uma arquitetura de aleatorização distribuída, que é abordada mais detalhadamente nesta Google Cloud publicação no blogue.

A execução de consultas do BigQuery é dinâmica. Um plano de consulta pode ser modificado enquanto a consulta está a ser processada. A distribuição do trabalho pode ser otimizada para a distribuição de dados à medida que são adicionadas fases. Além disso, a capacidade de execução de uma consulta pode mudar à medida que outras consultas são iniciadas ou terminadas, ou à medida que o escalador automático adiciona espaços a uma reserva.

O BigQuery pode executar várias fases em simultâneo, usar a execução especulativa para acelerar uma consulta e reparticionar dinamicamente uma fase para alcançar uma paralelização ideal.

Economia de recursos de slots

Se uma consulta necessitar de mais slots do que os que estão disponíveis, o BigQuery coloca em fila de espera as unidades de trabalho individuais e aguarda que os slots fiquem disponíveis. À medida que é feito progresso na execução da consulta e que os slots ficam disponíveis, estas unidades de tarefas em fila de espera são recolhidas dinamicamente para execução.

O BigQuery pode pedir qualquer número de slots para uma fase específica de uma consulta. O número de slots pedidos não está relacionado com a quantidade de capacidade que compra, mas sim com uma indicação do fator de paralelização mais otimizado escolhido pelo BigQuery para essa fase. As unidades de trabalho são colocadas em fila de espera e executadas à medida que os slots ficam disponíveis.

Quando as exigências de consultas excedem os espaços aos quais se comprometeu, não lhe são cobrados espaços adicionais nem tarifas a pedido adicionais. As suas unidades de trabalho individuais são colocadas em fila.

Por exemplo,

1. Uma fase de consulta pede 2000 espaços, mas apenas estão disponíveis 1000.
2. O BigQuery consome todos os 1000 slots e coloca os outros 1000 slots em fila.
3. Posteriormente, se 100 espaços terminarem o trabalho, selecionam dinamicamente 100 unidades de trabalho das 1000 unidades de trabalho em fila. 900 unidades de trabalho em fila de espera permanecem.
4. Posteriormente, se 500 espaços terminarem o trabalho, selecionam dinamicamente 500 unidades de trabalho das 900 unidades de trabalho em fila. Restam 400 unidades de trabalho em fila.

Slots do BigQuery em fila se a procura exceder a disponibilidade

Se a carga de trabalho exigir mais espaços do que os disponíveis para a reserva, o tempo de execução da tarefa pode aumentar à medida que as tarefas aguardam que os espaços fiquem disponíveis. Este processo é conhecido como concorrência de espaços. A contenção de espaços pode aumentar se a procura de carga de trabalho for muito superior aos espaços disponíveis para a reserva.

Priorização da capacidade

Quando o BigQuery regista uma procura elevada de recursos de slots numa região específica, gere a contenção dando prioridade à capacidade. Esta priorização garante que os clientes com modelos de capacidade de nível superior são menos afetados. O sistema dá prioridade à capacidade pela seguinte ordem:

1. Capacidades base e capacidade comprometida das edições Enterprise Plus e Enterprise.
2. Capacidade de escalonamento automático do Enterprise Plus.
3. Capacidade de escalonamento automático da edição Enterprise.
4. Edição padrão e capacidade a pedido.

Em caso de contenção numa região, é mais provável que os pedidos de capacidade da edição Standard e a pedido sofram atrasos no acesso, uma vez que o sistema atribui recursos primeiro às edições de nível superior.

Agendamento justo no BigQuery

O BigQuery atribui capacidade de slots numa única reserva através de um algoritmo denominado agendamento justo.

O agendador do BigQuery aplica a partilha igual de slots entre projetos com consultas em execução numa reserva e, em seguida, entre tarefas de um determinado projeto. O programador oferece equidade eventual. Durante períodos curtos, algumas tarefas podem receber uma quota desproporcionada de espaços, mas o agendador acaba por corrigir esta situação. O objetivo do programador é encontrar um equilíbrio entre desalojar agressivamente as tarefas em execução (o que resulta no desperdício de tempo de intervalo) e ser demasiado tolerante (o que resulta em trabalhos com tarefas de execução prolongada a receberem uma quota desproporcionada do tempo de intervalo).

O agendamento justo garante que todas as consultas têm acesso a todas as vagas disponíveis em qualquer altura e que a capacidade é realocada de forma dinâmica e automática entre as consultas ativas à medida que as exigências de capacidade de cada consulta mudam. As consultas são concluídas e são enviadas novas consultas para execução nas seguintes condições:

• Sempre que é enviada uma nova consulta, a capacidade é automaticamente reatribuída às consultas em execução. As unidades de trabalho individuais podem ser pausadas, retomadas e colocadas em fila de forma elegante à medida que fica disponível mais capacidade para cada consulta.
• Sempre que uma consulta é concluída, a capacidade consumida por essa consulta fica automaticamente disponível para utilização imediata por todas as outras consultas.
• Sempre que as exigências de capacidade de uma consulta mudam devido a alterações no DAG dinâmico da consulta, o BigQuery reavalia automaticamente a disponibilidade de capacidade para esta e todas as outras consultas, reatribuindo e pausando as posições, conforme necessário.

Agendamento justo no BigQuery

Consoante a complexidade e o tamanho, uma consulta pode não precisar de todos os espaços aos quais tem direito ou pode precisar de mais. O BigQuery garante dinamicamente que, com um planeamento justo, todos os espaços podem ser totalmente usados em qualquer momento.

Se um trabalho importante precisar sempre de mais espaços do que os que recebe do agendador, considere criar uma reserva adicional com o número necessário de espaços e atribuir o trabalho a essa reserva.

Como exemplo de agendamento justo, suponhamos que tem a seguinte configuração de reserva:

• Reserva A, que tem 1000 espaços de base sem escalabilidade automática
• Projeto A e projeto B, que estão atribuídos à sua reserva

Cenário 1: no projeto A, executa a consulta A (uma consulta simultânea) que requer uma elevada utilização de slots e, no projeto B, executa 20 consultas simultâneas. Embora haja um total de 21 consultas que estão a usar a reserva A, a distribuição de horários disponíveis é a seguinte:

• O projeto A recebe 500 espaços e a consulta A é executada com 500 espaços.
• O projeto B recebe 500 espaços que são partilhados entre as suas 20 consultas.

Cenário 2: no projeto A, executa a consulta A (uma consulta simultânea) que requer 100 espaços para execução e, no projeto B, executa 20 consultas simultâneas. Uma vez que a consulta A não requer 50% da reserva, a distribuição de ranhuras é a seguinte:

• O projeto A recebe 100 espaços e a consulta A é executada com 100 espaços.
• O projeto B recebe 900 vagas que são partilhadas entre as suas 20 consultas.

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

• A reserva B, que tem 1000 espaços de base sem dimensionamento automático.
• 10 projetos, todos atribuídos à reserva B.

Suponha que os 10 projetos estão a executar consultas com procura de espaços suficiente. Nesse caso, cada projeto recebe 1/10 do total de espaços de reserva (ou 100 espaços), independentemente do número de consultas que estão a ser executadas em cada projeto.

Quotas e limites de espaços

As quotas e os limites de slots oferecem uma salvaguarda para o BigQuery. Os diferentes modelos de preços usam diferentes tipos de quotas de espaços, da seguinte forma:

• Modelo de preços a pedido: está sujeito a um limite de espaços por projeto e organização com capacidade de picos transitórios. Consoante as suas cargas de trabalho, o acesso a mais espaços pode melhorar o desempenho das consultas.

• Modelo de preços baseado na capacidade: as quotas e os limites de reservas definem o número máximo de horários disponíveis que pode atribuir a todas as reservas numa localização. Se usar o dimensionamento automático, a soma dos tamanhos máximos das reservas não pode exceder este limite. Só lhe são cobradas as reservas e os compromissos, não as quotas. Para informações sobre como aumentar a quota de espaços, consulte o artigo Pedir um aumento da quota.

Para verificar quantos slots está a usar, consulte o artigo Monitorização do BigQuery.

Espaços inativos

Em qualquer altura, algumas ranhuras podem estar inativas. Isto pode incluir:

• Compromissos de slots que não estão atribuídos a nenhuma base de referência de reserva.
• Slots que estão alocados a uma base de referência de reserva, mas não estão a ser usados.

Os espaços inativos não são aplicáveis quando usa o modelo de preços a pedido.

Por predefinição, as consultas executadas numa reserva usam automaticamente espaços inativos de outras reservas na mesma região e projeto de administração. O BigQuery atribui imediatamente slots inativos a uma reserva atribuída quando são necessários. As ranhuras inativas que estavam a ser usadas por outra reserva são rapidamente anuladas se a reserva original o exigir. Pode haver um curto período em que o consumo total de espaços excede o máximo que especificou em todas as reservas, mas não lhe é cobrado este uso adicional de espaços.

Por exemplo, suponhamos que tem a seguinte configuração de reserva:

• O project_a está atribuído a reservation_a, que tem 500 vagas de base sem redimensionamento automático.
• project_b está atribuído a reservation_b, que tem 100 espaços de base sem escala automática.
• Ambas as reservas estão na mesma região e projeto administrativo, e não existem outros projetos atribuídos a estas reservas.

Corre query_b em project_b. Se não estiver a ser executada nenhuma consulta em project_a, então query_b tem acesso aos 500 espaços inativos de reservation_a. Enquanto o query_b ainda estiver em execução, pode usar até 600 espaços: 100 espaços de base mais 500 espaços inativos.

Enquanto o query_b está em execução, suponhamos que executa o query_a no project_a, que pode usar 500 espaços.

• Uma vez que tem 500 horários disponíveis de base reservados para project_a, query_a começa imediatamente e são-lhe atribuídos 500 horários disponíveis.
• O número de espaços atribuídos a query_b diminui rapidamente para 100 espaços de referência.
• As consultas adicionais executadas em project_b partilham essas 100 posições. Se as consultas subsequentes não tiverem espaços suficientes para começar, são colocadas em fila de espera até que as consultas em execução sejam concluídas e os espaços fiquem disponíveis.

Neste exemplo, se project_b foi atribuído a uma reserva sem intervalos de tempo de base nem escalamento automático, query_b não teria intervalos de tempo após o início da execução de query_a. O BigQuery pausa a consulta query_b até que os slots inativos fiquem disponíveis ou o tempo limite da consulta seja atingido. As consultas adicionais em project_b são colocadas em fila de espera até estarem disponíveis vagas.

Para garantir que uma reserva usa apenas os respetivos espaços aprovisionados, defina ignore_idle_slots como true. No entanto, as reservas com ignore_idle_slots definido como true podem partilhar os respetivos horários disponíveis com outras reservas.

Não pode partilhar espaços disponíveis entre reservas de diferentes edições. Só pode partilhar os espaços base ou os espaços comprometidos. Os horários com dimensionamento automático podem estar temporariamente disponíveis, mas não são partilháveis como horários inativos para outras reservas, porque podem ser reduzidos.

Enquanto ignore_idle_slots for falso, uma reserva pode ter uma contagem de horários disponíveis de 0 e continuar a ter acesso a horários disponíveis não usados. Se usar apenas a defaultreserva, desative ignore_idle_slots como prática recomendada. Em seguida, pode atribuir um projeto ou uma pasta a essa reserva, e esta só vai usar espaços disponíveis.

As atribuições do tipo ML_EXTERNAL são uma exceção, uma vez que os espaços usados por tarefas de criação de modelos externos do BigQuery ML não são preemptíveis. Os horários disponíveis numa reserva com os tipos de atribuição ML_EXTERNAL e QUERY só estão disponíveis para outros trabalhos de consulta quando não estão ocupados pelos trabalhos ML_EXTERNAL. Além disso, estas tarefas não podem usar espaços livres de outras reservas.

Equidade com base em reservas

Nota: tem de ativar a equidade baseada em reservas antes de poder criar uma reserva previsível.

Com a equidade baseada em reservas, o BigQuery prioriza e atribui slots inativos de forma igual em todas as reservas no mesmo projeto de administração, independentemente do número de projetos que executam tarefas em cada reserva. Cada reserva recebe uma quota semelhante da capacidade disponível no conjunto de espaços livres e, em seguida, os respetivos espaços são distribuídos de forma justa nos respetivos projetos. Esta funcionalidade só é suportada nas edições Enterprise ou Enterprise Plus.

O gráfico seguinte mostra como os espaços inativos são distribuídos sem a equidade baseada em reservas ativada:

Neste gráfico, os espaços inativos são partilhados igualmente entre os projetos.

Sem a equidade baseada em reservas ativada, os slots inativos disponíveis são distribuídos uniformemente pelos projetos nas reservas.

O gráfico seguinte mostra como os espaços ociosos são distribuídos com a equidade baseada em reservas ativada:

Neste gráfico, os espaços inativos são partilhados igualmente entre as reservas e não entre os projetos.

Com a equidade baseada em reservas ativada, os horários disponíveis inativos são distribuídos igualmente pelas reservas.

Quando ativa a equidade baseada em reservas, reveja o consumo de recursos para gerir a disponibilidade de slots e o desempenho das consultas.

Evite depender apenas de ranhuras inativas para cargas de trabalho de produção com requisitos de tempo rigorosos. Estas tarefas têm de usar ranhuras de base ou com dimensionamento automático. Recomendamos que use ranhuras inativas para tarefas de prioridade inferior, porque as ranhuras podem ser antecipadas em qualquer altura.

Escala automática de slots

A secção seguinte aborda as vagas de dimensionamento automático e como funcionam com as reservas.

Use reservas de escala automática

Não tem de comprar compromissos de espaços antes de criar reservas de dimensionamento automático. Os compromissos de slots oferecem uma tarifa com desconto para slots usados de forma consistente, mas são opcionais com reservas de dimensionamento automático. Para criar uma reserva de escalamento automático, atribui à reserva um número máximo de espaços (o tamanho máximo da reserva). Pode identificar o número máximo de horários de dimensionamento automático subtraindo o tamanho máximo da reserva a quaisquer horários base opcionais atribuídos à reserva.

Quando cria reservas de escalamento automático, tenha em atenção o seguinte:

• O BigQuery dimensiona as reservas quase instantaneamente até atingir o número de slots necessários para executar as tarefas ou atingir o número máximo de slots disponíveis para a reserva. Os espaços são sempre redimensionados automaticamente para um múltiplo de 50.
• O aumento da escala baseia-se na utilização real e é arredondado para o incremento de 50 slots mais próximo.
• Os seus slots com escalamento automático são cobrados ao preço de computação de capacidade para a edição associada durante o aumento da escala. É-lhe cobrado o número de ranhuras dimensionadas e não o número de ranhuras usadas. Esta cobrança aplica-se mesmo que o trabalho que faz com que o BigQuery seja dimensionado verticalmente falhe. Por este motivo, não use o esquema de informações de empregos para fazer corresponder a faturação. Em alternativa, consulte o artigo Monitorize o ajuste automático com o esquema de informações.
• Embora o número de espaços seja sempre dimensionado por múltiplos de 50, pode ser dimensionado para mais de 50 espaços num único passo. Por exemplo, se a sua carga de trabalho precisar de 450 slots adicionais, o BigQuery pode tentar dimensionar 450 slots de uma só vez para cumprir o requisito de capacidade.
• O BigQuery é reduzido quando as tarefas associadas à reserva já não precisam da capacidade (sujeito a um mínimo de 1 minuto).

Qualquer capacidade com ajuste automático é mantida durante, pelo menos, 60 segundos. Este período de 60 segundos é denominado período de redução. Qualquer novo pico na capacidade repõe o período de redução, tratando todo o nível de capacidade como uma nova concessão. No entanto, se tiverem passado 60 segundos ou mais desde o último aumento da capacidade e houver menos procura, o sistema reduz a capacidade sem repor a janela de redução, o que permite diminuições consecutivas sem um atraso imposto.

Por exemplo, se a capacidade de carga de trabalho inicial for dimensionada para 100 espaços, o pico é mantido durante, pelo menos, 60 segundos. Se, durante esse período de redução, a sua carga de trabalho for dimensionada para um novo pico de 200 espaços, começa um novo período de redução de 60 segundos. Se não houver um novo pico durante este período de redução, a sua carga de trabalho começa a ser reduzida no final dos 60 segundos.

Considere o seguinte exemplo detalhado: às 12:00:00, a sua capacidade inicial é dimensionada para 100 vagas e a utilização dura um segundo. Esse pico é mantido durante, pelo menos, 60 segundos, a partir das 12:00:00. Após os 60 segundos, se a nova utilização for de 50 slots, o BigQuery reduz a escala para 50 slots. Se, às 12:01:02, a nova utilização for de 0 slots, o BigQuery volta a reduzir imediatamente para 0 slots. Após o fim do período de redução, o BigQuery pode reduzir várias vezes consecutivas sem precisar de um novo período de redução.

Para saber como trabalhar com o dimensionamento automático, consulte o artigo Trabalhe com espaços de dimensionamento automático.

Usar reservas com base e intervalos de dimensionamento automático

Além de especificar o tamanho máximo da reserva, pode opcionalmente especificar um número base de horários disponíveis por reserva. A base é o número mínimo de espaços que são sempre atribuídos à reserva e pelos quais é sempre cobrado. Os espaços de ajuste automático só são adicionados depois de todos os espaços de base (e espaços inativos, se aplicável) serem consumidos. Pode partilhar espaços de base ociosos numa reserva com outras reservas que precisem de capacidade.

Pode aumentar o número de espaços base numa reserva a cada poucos minutos. Se quiser diminuir os seus espaços de referência, tem um limite de uma vez por hora se tiver alterado recentemente a capacidade dos espaços de referência e os seus espaços de referência excederem os espaços comprometidos. Caso contrário, pode diminuir os seus horários de base a cada poucos minutos.

Os slots de base e de escalabilidade automática destinam-se a fornecer capacidade com base na sua carga de trabalho recente. Se prevê uma carga de trabalho grande muito diferente das suas cargas de trabalho no passado recente, recomendamos que aumente a capacidade de base antes do evento, em vez de confiar nos espaços de dimensionamento automático para cobrir a capacidade de carga de trabalho. Se tiver um problema ao aumentar a capacidade base, tente novamente o pedido após 15 minutos.

Se a reserva não tiver espaços base ou não estiver configurada para pedir emprestados espaços inativos a outras reservas, o BigQuery tenta dimensionar. Caso contrário, os espaços base têm de ser totalmente utilizados antes do dimensionamento.

As reservas usam e adicionam espaços na seguinte prioridade:

1. Intervalos de base.
2. Partilha de espaços inativos (se ativada). As reservas só podem partilhar a base de referência inativa ou os espaços comprometidos de outras reservas criadas com a mesma edição e a mesma região.
3. Ajuste automático dos espaços.

No exemplo seguinte, os espaços aumentam a partir de um valor base especificado. As reservas de etl e dashboard têm um tamanho base de 700 e 300 espaços, respetivamente.

Neste exemplo, a reserva etl pode ser dimensionada para 1300 espaços (700 espaços de base mais 600 espaços de dimensionamento automático). Se a reserva dashboard não estiver em uso, a reserva etl pode usar os 300 espaços da reserva dashboard se não estiver a ser executado nenhum trabalho, o que resulta num máximo de 1600 espaços possíveis.

A reserva de dashboard pode ser dimensionada até 1100 espaços (300 espaços de base mais 800 espaços de dimensionamento automático). Se a reserva etl estiver totalmente inativa, a reserva dashboard pode ser dimensionada para um máximo de 1800 espaços (300 espaços de base + 800 espaços de dimensionamento automático + 700 espaços inativos na reserva etl).

Se a reserva etl exigir mais de 700 espaços base, que estão sempre disponíveis, tenta adicionar espaços através dos seguintes métodos pela seguinte ordem:

1. 700 espaços de base.
2. Partilha de horários disponíveis com os 300 horários de referência na reserva dashboard. A sua reserva só partilha horários de base inativos com outras reservas criadas com a mesma edição.
3. Aumentar 600 espaços adicionais até ao tamanho máximo da reserva.

Usar compromissos de slots

O exemplo seguinte mostra as posições de dimensionamento automático através de compromissos de capacidade.

Tal como as bases de referência de reservas, os compromissos de horários disponíveis permitem-lhe atribuir um número fixo de horários disponíveis que estão disponíveis para todas as reservas. Ao contrário dos espaços base, não é possível reduzir um compromisso durante o prazo. Os compromissos de faixas horárias são opcionais, mas podem poupar custos se forem necessárias faixas horárias de base durante longos períodos. Os compromissos de slots são usados para cobrir os slots de base das suas reservas. A capacidade de horários não utilizada é partilhada como horários disponíveis noutras reservas. Os compromissos de espaços não se aplicam a espaços de ajuste automático. Para garantir que recebe a tarifa com desconto para os seus espaços comprometidos, certifique-se de que os seus compromissos de espaços são suficientes para cobrir os espaços base.

Neste exemplo, é-lhe cobrada uma taxa predefinida pelos espaços de compromisso de capacidade. É-lhe cobrada a taxa de dimensionamento automático para o número de espaços de dimensionamento automático após a ativação do dimensionamento automático e quando as reservas estão num estado de aumento de escala. Para a taxa de dimensionamento automático, é-lhe cobrado o número de espaços dimensionados e não o número de espaços usados.

O exemplo seguinte mostra as reservas quando o número de espaços de base excede o número de espaços comprometidos.

Neste exemplo, existem um total de 1000 posições de base entre as duas reservas, 500 da reserva etl e 500 da reserva dashboard. No entanto, o compromisso abrange apenas 800 espaços. Neste cenário, os slots em excesso são cobrados à taxa de pagamento conforme o uso (PAYG).

Número máximo de vagas disponíveis

Pode calcular o número máximo de horários disponíveis que uma reserva pode usar adicionando os horários disponíveis de base, o número máximo de horários disponíveis de dimensionamento automático e quaisquer horários disponíveis em compromissos que foram criados com a mesma edição e não estão cobertos pelos horários disponíveis de base. O exemplo na imagem anterior está configurado da seguinte forma:

• Um compromisso de capacidade de 1000 slots anuais. Esses horários são atribuídos como horários de base na reserva etl e na reserva dashboard.
• 700 horários base atribuídos à reserva etl.
• 300 espaços base atribuídos à reserva dashboard.
• Aumente automaticamente os espaços de 600 para a reserva de etl.
• Aumente automaticamente os espaços de 800 para a reserva dashboard.

Para a reserva etl, o número máximo de espaços possíveis é igual aos espaços de base etl (700) mais os espaços de base dashboard (300, se todos os espaços estiverem inativos) mais o número máximo de espaços de dimensionamento automático (600). Assim, o número máximo de espaços que a reserva etl poderia usar neste exemplo é 1600. Este número excede o número no compromisso de capacidade.

No exemplo seguinte, o compromisso anual excede os espaços base atribuídos.

Neste exemplo, temos:

• Um compromisso de capacidade de 1600 vagas anuais.
• Um tamanho máximo de reserva de 1500 (incluindo 500 espaços de ajuste automático).
• 1000 horários base atribuídos à reserva etl.

O número máximo de espaços disponíveis para a reserva é igual aos espaços de base (1000) mais quaisquer espaços inativos comprometidos não dedicados aos espaços de base (1600 espaços anuais - 1000 espaços de base = 600) mais o número de espaços de dimensionamento automático (500). Assim, o número máximo de espaços potenciais nesta reserva é 2100. Os slots com ajuste automático são slots adicionais acima do compromisso de capacidade.

Práticas recomendadas para o dimensionamento automático

1. Quando usar o dimensionamento automático pela primeira vez, defina o número de vagas de dimensionamento automático para um número significativo com base no desempenho passado e esperado. Depois de criar a reserva, monitorize ativamente a taxa de falhas, o desempenho e a fatura, e ajuste o número de vagas de dimensionamento automático conforme necessário.

2. O escalador automático tem um mínimo de 1 minuto antes de reduzir a escala, por isso, é importante definir o número máximo de espaços com ajuste automático para equilibrar o desempenho e o custo. Se o número máximo de espaços de ajuste automático for demasiado grande e a sua tarefa puder usar todos os espaços para concluir uma tarefa em segundos, continua a incorrer em custos pelos espaços máximos durante o minuto completo. Se reduzir o número máximo de espaços para metade do valor atual, a reserva é dimensionada para um número inferior e a tarefa pode usar mais slot_seconds durante esse minuto, o que reduz o desperdício. Para obter ajuda na determinação dos requisitos de espaço, consulte o artigo Monitorize o desempenho das tarefas. Como abordagem alternativa para determinar os requisitos de slots, consulte o artigo Veja as recomendações de slots de edições.

3. A utilização de espaços pode exceder ocasionalmente a soma do valor de referência e dos espaços dimensionados. Não lhe é cobrada a utilização de espaços superior à sua base mais espaços dimensionados.

4. O escalonamento automático é 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, uma vez que cada consulta dimensiona a reserva, onde permanece dimensionada durante um mínimo de 1 minuto. Se enviar consultas continuamente, o que gera uma carga de trabalho constante, definir uma base e comprar um compromisso oferece capacidade constante a um preço com desconto.

5. O ajuste de escala automático do BigQuery está sujeito à disponibilidade de capacidade. O BigQuery tenta satisfazer a procura de capacidade dos clientes com base no histórico de utilização. Para alcançar garantias de capacidade, pode definir uma base opcional de espaços, que é o número de espaços garantidos numa reserva. Com as bases, os espaços ficam imediatamente disponíveis e paga por eles, quer os use ou não. Para garantir que a capacidade está disponível para grandes procuras não orgânicas, como feriados com tráfego elevado, contacte a equipa do BigQuery com várias semanas de antecedência.

6. Os espaços base são sempre cobrados. Se um compromisso de capacidade expirar, pode ter de ajustar manualmente a quantidade de espaços base nas suas reservas para evitar cobranças indesejadas. Por exemplo, considere que tem um compromisso de 1 ano com 100 posições e uma reserva com 100 posições de base. O compromisso expira e não tem um plano de renovação. Quando o compromisso expira, paga 100 espaços base à tarifa de pagamento à medida do uso.

Monitorize a escala automática

Para informações sobre a monitorização da utilização de espaços e do desempenho das tarefas com a escala automática, consulte o artigo Monitorize a escala automática.

Utilização excessiva de slots

Quando uma tarefa retém posições durante demasiado tempo, pode receber uma quota injusta de posições. Para evitar atrasos, o BigQuery permite que outras tarefas peçam emprestados slots adicionais, o que resulta em períodos de utilização total de slots acima da capacidade de slots especificada. A utilização excessiva de ranhuras é atribuída apenas às tarefas que recebem mais do que a sua quota-parte.

Os espaços em excesso não são faturados diretamente à sua conta. Em alternativa, as tarefas continuam a ser executadas e a acumular a utilização de slots na sua quota-parte até que toda a utilização excessiva seja coberta pela capacidade atribuída. Os espaços em excesso são excluídos da utilização de espaços comunicada, exceto em determinadas estatísticas de execução detalhadas.

Tenha em atenção que pode ocorrer algum empréstimo preventivo de espaços para reduzir atrasos futuros e oferecer outras vantagens, como a redução da variabilidade do custo dos espaços e a redução da latência da cauda. A utilização de espaços emprestados está limitada a uma pequena fração da sua capacidade total de espaços.