Otimizar o armazenamento no BigQuery

Nesta página, apresentamos práticas recomendadas para otimizar o armazenamento do BigQuery. O BigQuery armazena dados em formato de colunas. Os bancos de dados orientados por coluna são otimizados para cargas de trabalho analíticas que agregam dados sobre um número muito grande de registros. Como as colunas costumam ter mais redundância do que as linhas, essa característica permite uma maior compactação de dados usando técnicas como codificação de duração de execução. Para mais informações sobre como o BigQuery armazena dados, consulte Informações gerais do armazenamento do BigQuery. A otimização do armazenamento do BigQuery melhora o desempenho da consulta e o controle de custos.

O BigQuery fornece detalhes sobre o consumo de armazenamento dos recursos. Para acessar os metadados de armazenamento de tabelas, consulte as seguintes visualizações INFORMATION_SCHEMA:

Dados da tabela de clusters

Práticas recomendadas: crie tabelas em cluster.

Para otimizar o armazenamento de consultas, comece agrupando os dados da tabela em cluster. Ao agrupar colunas usadas com frequência, é possível reduzir o volume total de dados verificados pela consulta. Para informações sobre como criar clusters, consulte Criar e usar tabelas em cluster.

Dados da tabela de partições

Prática recomendada: divida tabelas grandes com partições.

Com as partições, é possível agrupar e classificar os dados por um conjunto de características de coluna definidas, como uma coluna de número inteiro, uma coluna de unidade de tempo ou o tempo de ingestão. O particionamento melhora o desempenho da consulta e os custos de controle, reduzindo o número de bytes lidos por uma consulta.

Para mais informações sobre partições, consulte Introdução às tabelas particionadas.

Usar as configurações de expiração de tabela e partições

Prática recomendada: para otimizar o armazenamento, defina as configurações de expiração padrão paraconjuntos de dados ,mesas etabelas particionadas de dois minutos.

Controle custos de armazenamento e otimize o uso dele definindo a validade padrão da tabela para tabelas recém-criadas em um conjunto de dados. Quando uma tabela expira, ela é excluída com todos os dados que ela contém. Se você definir a propriedade quando o conjunto de dados for criado, qualquer tabela criada no conjunto de dados será excluída depois do período de expiração. Se você definir a propriedade depois que o conjunto de dados tiver sido criado, somente as novas tabelas serão excluídas depois do período de expiração.

Por exemplo, se você definir a expiração da tabela padrão como sete dias, os dados mais antigos serão excluídos automaticamente depois de uma semana.

Essa opção será útil se você precisar ter acesso apenas aos dados mais recentes. Isso também será útil se você estiver fazendo testes com dados e não precisar preservá-los.

Se as tabelas forem particionadas por data, a expiração da tabela padrão do conjunto de dados se aplicará às partições individuais. Também é possível controlar a validade da partição usando a sinalização time_partitioning_expiration na ferramenta de linha de comando bq ou a configuração expirationMs na API. Quando uma partição expira, os dados dela são excluídos, mas a tabela particionada não é descartada mesmo que a tabela esteja vazia. Por exemplo, o comando a seguir expira as partições após três dias:

bq mk \
--time_partitioning_type=DAY \
--time_partitioning_expiration=259200 \
project_id:dataset.table

Armazene os dados no BigQuery

Prática recomendada: armazene seus dados no BigQuery.

Quando dados são carregados no BigQuery a partir do Cloud Storage, não há cobrança pela operação de carregamento, apenas pelo armazenamento dos dados no Cloud Storage. Depois que os dados são carregados no BigQuery, eles estão sujeitos aos preços de armazenamento do BigQuery. Você é cobrado pelo armazenamento físico ou lógico que sua tabela consome, incluindo os blocos de armazenamento de viagem no tempo.

Em vez de exportar dados mais antigos para outra opção de armazenamento (como o Cloud Storage), aproveite os preços de armazenamento em longo prazo do BigQuery.

Se você tem uma tabela que não é editada por 90 dias consecutivos, o preço do armazenamento dessa tabela diminui automaticamente em 50%. Se você tiver uma tabela particionada, cada partição será considerada separadamente para qualificação para preços de longo prazo sujeitos às mesmas regras das tabelas não particionadas.

Identificar dados de longo ou curto prazo

Prática recomendada: identifique se os dados no nível da linha precisam ser armazenados em longo prazo e armazene apenas dados agregados de longo prazo.

Em muitos casos, os detalhes contidos nos dados transacionais ou no nível da linha são úteis a curto prazo, mas são menos referenciados a longo prazo. Nessas situações, é possível criar consultas de agregação para calcular e armazenar as métricas associadas a esses dados e, em seguida, usar a expiração da tabela ou partição para remover sistematicamente os dados no nível da linha. Isso reduz as cobranças de armazenamento e mantém as métricas disponíveis para consumo de longo prazo.

Reduzir a janela de viagem no tempo

Prática recomendada: com base no seu requisito, você pode reduzir a janela de viagem no tempo.

Reduzir os dias de viagem no tempo do valor padrão de sete reduz o número total de blocos de armazenamento armazenados para um objeto. A janela de viagem no tempo é definida no nível do conjunto de dados.

Arquivar dados para o Cloud Storage

Prática recomendada: arquive dados no Cloud Storage.

Mova os dados do BigQuery para o Cloud Storage com base na necessidade comercial de arquivamento. Como prática recomendada, considere os preços de longo prazo do BigQuery antes de exportar dados do BigQuery.

A seguir