BigQuery - Inserindo 1 milhão de registros em segundos (Google Cloud Plataform).

    Neste estudo de caso do blog, demonstraremos o INSERT de arquivos JSON em Tabelas BigQuery.

Milhões de registros (direto de arquivos físicos heim, acredite rs) em questões de Segundos;

Existem outros cenários, de maior preformance que abordaremos nos proximos post; como exemplos Datasets públicos sendo migrados e copiados em décimos de segundo...

• NYC Taxi Fares +/- 36 milhoes de registros disponiveis de tarifas dos taxis americanos (bigquery-public-data.new_york_taxi_trips.tlc_yellow_trips_2022)

• Wikipedia the massive database; como eles mesmo se apresentam "Um gigantesco" Database, que inclui dados de tráfego de cada página da Wikipedia (bigquery-public-data.wikipedia.pageviews_2023)

*  FILTRO / (Partition elimination) Aproximadamente 4,4 bilhoes de registros; em Um (1) Unico mês, 30 Dias rs;

** Cuidado: LEMBRAMOS  QUE  CONSUMO (QUERY) ACIMA DE 1 TB (um terabyte) MÊS / SERÁ COBRADO ADICIONAL; FIQUE ATENTO, rs ...

Para a preparação, vamos criar um arquivo de texto com 1 milhão de linhas em formato JSON, utilizando um script automático em Python.

Primeira Etapa 1)

Faremos uma abordagem mais simples: ler o arquivo de texto/JSON linha por linha e inserir na mesma tabela do BigQuery, uma de cada vez. Segundo a documentação do BigQuery Streaming Insert, é possível inserir várias linhas em uma única chamada da API.

https://cloud.google.com/bigquery/docs/streaming-data-into-bigquery

Neste diagrama, existem três componentes principais:

1. File Reader: Realiza a leitura simples de arquivos de texto, encaminhando o conteúdo (linhas) para o Canal.

2. Canal (c1 e c2): Responsável por compartilhar os dados em formato de cadeia de caracteres de texto. Ele prepara e envia o buffer de strings.

3. Work: Responsável por inserir os dados em uma tabela do BigQuery.

Channel é uma estrutura nativa da linguagem Go, utilizada para comunicar e sincronizar co-rotinas (goroutines).
Eu gosto de assimilar o conceito de channel a threads da CPU, embora não sejam gerenciadas pelo sistema operacional. Eles não bloqueiam nem interferem nas threads do sistema operacional, tornando a execução mais eficiente.

Os canais são bi-direcionais, permitindo a passagem de dados. Quando concluído, o conteúdo segue através do pipe para o Worker.

Para a terceira e última etapa, utilizaremos a goroutine do Go. O Go permite a sincronização de milhares ou até milhões de goroutines em execução paralela. Essas execuções simultâneas são significativamente mais rápidas do que outras formas de agendamento, já que as goroutines são muito leves (cerca de 2 KB de stack cada, podendo crescer conforme necessário).

Para decidir o número máximo de buffers e workers, é importante entender as cotas e os limites da API BigQuery Streaming, conforme descrito na documentação:

Cotas e limites  |  BigQuery  |  Google Cloud

 

Usando a configuração mais alta

Conseguimos inserir (1) um milhão de linhas em apenas 14 segundos!

Conclusão

Neste caso de teste do blog, aprendemos a aplicar os conceitos de simultaneidade e goroutines para fazer com que nossos "Jobs" (INSERT) aproveitem ao máximo os recursos da tecnologia BigQuery, executando tarefas simultâneas de forma incrivelmente mais rápida.

Evidências:

Performance extrema, com DynamoDB (DAX) Accelerator

 O Amazon DynamoDB foi concebido para escala e performance. Na maioria dos casos, os tempos de resposta do DynamoDB podem ser medidos em milissegundos de um dígito. No entanto, existem certos casos de uso que exigem tempos de resposta em microssegundos. Para esses casos de uso, o DynamoDB Accelerator (DAX) oferece tempos de resposta rápidos para acessar dados finais consistentes.

O DAX é um serviço de armazenamento em cache compatível com o DynamoDB no qual você pode se beneficiar da rápida performance em memória para aplicações exigentes. O DAX lida com três cenários principais:

1. Como um cache na memória, o DAX reduz os tempos de resposta de workloads de leitura final consistente por uma ordem de magnitude que varia de milissegundos de um único dígito até microssegundos.

2. O DAX reduz a complexidade operacional e da aplicação fornecendo um serviço gerenciado que é compatível com a API do DynamoDB. Portanto, ele exige apenas alterações funcionais mínimas para uso com um aplicativo existente.

3. Para workloads de leitura intermitentes ou pesadas, o DAX fornece throughput mais alto e economia potencial de custos operacionais reduzindo a necessidade de provisionar unidades de capacidade de leitura em excesso. Isso é especialmente benéfico para aplicativos que exigem leituras repetidas para chaves individuais.

O DAX é compatível com a criptografia do lado do servidor. Com a criptografia em repouso, os dados persistentes pelo DAX no disco serão criptografados. O DAX grava dados ao disco como parte das alterações de propagação do nó primário para as réplicas de leitura. 

O DAX também oferece suporte à criptografia em trânsito, garantindo que todas as solicitações e respostas entre a aplicação e o cluster sejam criptografadas por TLS (Transport Level Security) e que as conexões com o cluster possam ser autenticadas pela verificação de um certificado de cluster. .

O DAX dá acesso a dados finais consistentes de tabelas do DynamoDB, com latência de microssegundos. Um cluster do DAX multi-AZ pode servir milhões de solicitações por segundo.

O DAX é ideal para os seguintes tipos de aplicações:

• Aplicativos que exigem o melhor tempo de resposta possível para leituras. Alguns exemplos incluem lances em tempo real, jogos sociais e aplicações de negócios. O DAX oferece uma performance de leitura rápida na memória para esses casos de uso.

• Aplicativos que fazem a leitura de um pequeno número de itens com mais frequência do que outros. Por exemplo, considere um sistema de comércio eletrônico que tem uma promoção de um produto popular válida por apenas um dia. Durante a promoção, a demanda por esse produto (e seus dados no DynamoDB) aumentaria drasticamente em comparação a todos os outros produtos. Para mitigar os impactos de uma chave de "aceleração" e uma distribuição de tráfego não uniforme, você pode descarregar as atividades de leitura em um cache do DAX até que essa promoção de um dia acabe.

• Aplicativos que exigem leitura intensa, mas que também são sensíveis aos custos. Com o DynamoDB, você fornece o número de leituras por segundo que a sua aplicação exige. Se as atividades de leitura aumentarem, você poderá aumentar o throughput de leitura provisionado das suas tabelas (a um custo adicional). Como alternativa, é possível descarregar as atividades da sua aplicação em um cluster do DAX e reduzir a quantidade de unidades de capacidade de leitura que você precisa comprar.

• Aplicativos que exigem leituras repetidas em um grande conjunto de dados. Esses aplicativos poderiam desviar os recursos de banco de dados de outros aplicativos. Por exemplo, uma análise de longa execução de dados meteorológicos regionais pode consumir toda a capacidade de leitura em uma tabela do DynamoDB. Essa situação pode afetar negativamente outros aplicativos que precisam acessar os mesmos dados. Com o DAX, a análise meteorológica pode ser realizada com base nos dados em cache.

O DAX não é ideal para os seguintes tipos de aplicação:

• Aplicativos que exigem leituras fortemente consistentes (ou que não toleram leituras eventualmente consistentes).

• Aplicativos que não precisam de tempos de resposta em microssegundos para leituras ou descarregar atividades de leitura repetidas de tabelas subjacentes.

• Aplicações que exigem alto volume de gravações. O alto volume de gravações leva ao aumento da replicação entre nós do DAX em um cluster. Isso causa um aumento no consumo de recursos e no risco de problemas de disponibilidade.

• Aplicações sem muitas leituras repetidas. O DAX tem melhor desempenho quando as taxas de acertos de cache excedem 90%. Taxas de acertos de cache mais baixas aumentam as perdas no cache, o que consome mais recursos em todo o cluster do DAX.