avisar que bases bdpro não tem isso por uma limitação do BigQuery
########################
Entenda o uso gratuito do Big Query (BQ)
Para usuários que acessam os dados em projetos públicos como o da Base dos Dados o único tipo de custo associado se refere ao custo de processamento das consultas. A notícia boa é que todo usuário possui *1 TB gratuito por mês para consultar livremente os dados do maior data lake público do Brasil!.
Pontos de destaque:
Nenhuma cobrança automática é feita ao usuário caso o limite de 1 TB/mês seja excedido.
Se você ainda não possui um projeto no BQ consulte nosso guia para criá-lo.
Conhecer o básico da interface do BQ facilitará o entendimento do artigo. Para tal sugerimos a [documentação oficial](- Guia da interface do Big Query) e também nosso acervo de vídeos no youtube
Como usufruir ao máximo das consultas gratuitas
Nesta seção apresentamos algumas dicas simples para reduzir os custos das consulta e aproveitar ao máximo os dados da BD!
Antes de partir para os exemplos, apresentaremos o mecanismo básico de previsão de custos de processamento de consultas no Big Query (BQ).
Estimativas de Custos de processamento
No canto superior direito da interface do BQ é informado um aviso com estimativa do custo de processamento que será cobrado do seu projeto apos a execução da consulta.
- Este é o mecanismo básico e prontamente acessível de previsibilidade do custo.
- Por motivos de limitação interna do próprio Big Query consultas a tabelas específicas não exibem estimativas de custos. É o caso das tabelas que possuem Row Access Policy. Isto é, tabelas onde o número de linhas acessíveis é limitada a depender do usuário. Este é o caso das tabelas que fazem parte do serviço [BDpro](https://info.basedosdados.org/bd-pro)
Selecione somente as colunas de interesse
No Big Query os dados possuem o armazenamento orientado a colunas, isto é, cada coluna é armazenada separadamente. Esta característica tem uma implicação clara quanto aos custos de processamento: quanto mais colunas forem selecionadas, maior será o custo.
Evite: Selecionar colunas em excesso
SELECT *
Prática recomendada: selecione somente as colunas de interesse para reduzir o custo final da consulta.
SELECT sequencial_obito, tipo_obito, data_obito FROM `basedosdados.br_ms_sim.microdados
custo estimado: 531MB
SELECT * FROM `basedosdados.br_ms_sim.microdados
custo estimado: 5.83 GB
Para entender mais a fundo a arquitetura colunar consulte a documentação oficial do Big Query
Utilize colunas particionadas para filtrar os dados
As partições são divisões feitas em uma tabela para facilitar o gerenciamento e a consulta dos dados. No momento de execução da consulta o Big Query ignora linhas que possuem um valor da partição diferente do utilizado no filtro. Isto normalmente reduz significativamente a quantidade de linhas lidas e, o que nos interessa, reduz o custo de processamento.
Como saber qual coluna foi utilizada para particionar uma tabela específica?
Pelos metadados na página de 'Detalhes' no Big Query
Prática recomendada: sempre que possível, utilize colunas particionadas para filtrar os dados.
Exemplo
Consulta utilizado a coluna particionada como filtro:
SELECT sequencial_obito, tipo_obito, data_obito FROM `basedosdados.br_ms_sim.microdados` where ano = 2015
custo estimado: 31.32 MB
Muita atenção ao realizar joins entre tabelas
Avalie a real necessidade do JOIN
Certifique-se de que o join é realmente necessário para a análise que você está realizando. Às vezes, operações alternativas como subconsultas ou agregações podem ser mais eficientes.
Entenda a Lógica do JOIN
Diferentes tipos de joins (INNER, LEFT, RIGHT, FULL) têm diferentes implicações de desempenho e resultado. Gastar um tempinho entendo a melhor opção para seu objetivo de análise pode ajudar a ter um controle de custos mais eficiênte.
Um dos problemas que geralmente ocorrem é a multiplicação de linhas indesejadas no resultado final.
Utilize as dicas anteriores
Selecione somente colunas de interesse
Faça uso das colunas particionadas para filtrar os dados
Atente-se a estimativa de custos antes de executar a consulta
########################
Para usuários que acessam os dados em projetos públicos como o da Base dos Dados o único tipo de custo associado se refere ao custo de processamento das consultas. A notícia boa é que todo usuário possui *1 TB gratuito por mês para consultar livremente os dados do maior data lake público do Brasil!.
Pontos de destaque:
Nesta seção apresentamos algumas dicas simples para reduzir os custos das consulta e aproveitar ao máximo os dados da BD!
Antes de partir para os exemplos, apresentaremos o mecanismo básico de previsão de custos de processamento de consultas no Big Query (BQ).
Selecione somente as colunas de interesse
No Big Query os dados possuem o armazenamento orientado a colunas, isto é, cada coluna é armazenada separadamente. Esta característica tem uma implicação clara quanto aos custos de processamento: quanto mais colunas forem selecionadas, maior será o custo.
Evite: Selecionar colunas em excesso
SELECT *Prática recomendada: selecione somente as colunas de interesse para reduzir o custo final da consulta.
SELECT coluna1, coluna2Exemplo: tabela microdados do conjunto br_ms_sim.
SELECT sequencial_obito, tipo_obito, data_obito FROM `basedosdados.br_ms_sim.microdadosSELECT * FROM `basedosdados.br_ms_sim.microdadosPara entender mais a fundo a arquitetura colunar consulte a documentação oficial do Big Query
Utilize colunas particionadas para filtrar os dados
As partições são divisões feitas em uma tabela para facilitar o gerenciamento e a consulta dos dados. No momento de execução da consulta o Big Query ignora linhas que possuem um valor da partição diferente do utilizado no filtro. Isto normalmente reduz significativamente a quantidade de linhas lidas e, o que nos interessa, reduz o custo de processamento.
Como saber qual coluna foi utilizada para particionar uma tabela específica?
Pelos metadados na página de tabela do site da BD
Pelos metadados na página de 'Detalhes' no Big Query
SELECT sequencial_obito, tipo_obito, data_obito FROM `basedosdados.br_ms_sim.microdados` where ano = 2015Muita atenção ao realizar joins entre tabelas