Otimizar o desempenho de coleções de análises externas no Couchbase

É fundamental planejar a otimização do desempenho e a utilização de recursos agora que há suporte para coleções externas do Couchbase Analytics (AWS S3 e Armazenamento de Blobs do Azure). As coleções externas do Couchbase Analytics leem os dados do armazenamento externo e não os armazenam localmente, o que pode ser uma operação cara se não for otimizada.

Este artigo discute os fatores que afetam significativamente o desempenho e a utilização de recursos ao consultar dados do armazenamento externo. Também analisaremos um exemplo detalhado para ver como nossas otimizações podem ser eficazes.

Consideraremos os itens a seguir e discutiremos seu impacto sobre o desempenho e a utilização de recursos:

• Largura de banda da Internet e distância do armazenamento externo
• Número de nós e partições do Couchbase Analytics e número de arquivos no armazenamento externo
• Prefixos e filtros de inclusão/exclusão

Largura de banda e distância da Internet

Como os dados externos não são armazenados no armazenamento nativo do Couchbase Analytics, cada solicitação de consulta transfere a versão atual dos dados pela rede. Isso faz com que a largura de banda da rede seja um fator significativo no desempenho de tais consultas. A latência da rede é outro fator - a distância que os dados têm de percorrer afetará a latência. Portanto, é recomendável que o armazenamento de destino seja hospedado em uma região próxima.

Observação: alguns provedores de serviços de armazenamento não cobram nenhum custo de transmissão se o aplicativo e o armazenamento do host estiverem na mesma região, o que melhora o desempenho e reduz os custos.

Partições vs. número de arquivos

Ao consultar uma coleção externa do Couchbase Analytics, a carga de trabalho de varredura de dados será distribuída uniformemente pelos nós e partições disponíveis do Analytics para ler os dados em paralelo. (Isso é semelhante a como o armazenamento interno é ler em paralelo). Para garantir que esse recurso de leitura paralela seja totalmente utilizado, os dados no armazenamento externo devem ser armazenados em vários arquivos em vez de em um ou alguns arquivos grandes.

Por exemplo, vamos supor que temos três nós do Analytics com quatro partições por nó. Essa configuração resulta em um grau paralelo de 12 (12 partições no total). Quando uma coleção externa do Analytics é consultada, ela deve ser capaz de ler 12 arquivos em paralelo do armazenamento externo.

Se tivermos nossos dados organizados em vários arquivos, a configuração acima lerá 12 arquivos por vez, mas se tivermos apenas alguns arquivos (por exemplo, cinco arquivos grandes), somente cinco partições terão trabalho a fazer, deixando o restante dos recursos do Analytics disponíveis ociosos.

O objetivo do Analytics é distribuir a carga de trabalho de varredura uniformemente entre o número total de partições, não entre os nós. No exemplo acima, cada uma das 12 partições terá 1/12 da carga de trabalho total e cada nó terá 1/3 da carga. Se os nós tivessem números diferentes de partições por algum motivo, a carga de trabalho por partição permaneceria uniforme, mas os próprios nós seriam carregados de forma não uniforme. É por isso que é recomendável ter os dados distribuídos em vários arquivos para que a carga de trabalho possa ser distribuída. 

No entanto, é igualmente crucial evitar ter muitos arquivos pequenos como centenas de milhares ou milhões de arquivos, pois isso poderia resultar em baixo desempenho devido ao manuseio de metadados de arquivos e ao excesso de operações de abertura/fechamento de arquivos.

Prefixos e filtros de inclusão/exclusão

Organização de dados

Vamos começar examinando a estrutura dos dados com os quais trabalharemos aqui para ilustrar. Trabalharemos com três anos de revisões dados. Organizaremos nossos dados por ano, por trimestre e por mês. Os dados são para os anos de 2018, 2019 e 2020.

Aqui estão exemplos do layout do diretório e de um documento típico:

Amostra de documento:

A estrutura acima nos permitirá ter uma granularidade por mês sobre os dados, que utilizaremos em outros exemplos.

Vamos supor que o tamanho total de nossos dados para os três anos seja de 720 GB. Isso nos dá cerca de 240 GB de dados por ano (três anos) e 20 GB por mês (36 meses em três anos).

Como funcionam as coleções externas?

Como a organização dos dados pode afetar significativamente o desempenho, vamos rever como o Couchbase Analytics lê os dados do armazenamento externo.

Os dados das coleções de análise externa são armazenados em um armazenamento externo remoto, como o AWS S3, o Azure Blob/Data Lake ou o Google Cloud Storage. O Azure Blob Storage e o Google Cloud Storage são atualmente em visualização para desenvolvedores. 

Quando um link externo e uma coleção externa do Analytics são criados, eles são definições de entidades configuradas para ler os dados da fonte externa, mas os dados não são armazenado no Analytics. Isso permite que o Analytics sempre veja as versões mais recentes dos dados externos, mas também pode ser lento. Podemos otimizar o processo de leitura usando prefixos e outros filtros para economizar tempo e recursos.

No exemplo a seguir, veremos a grande diferença que um filtro pode fazer se for usado criteriosamente em conjunto com dados bem organizados.

Requisitos

Vamos dar uma olhada nas seguintes solicitações de consulta simples para ver a diferença de desempenho com e sem filtragem:

• Obtenha o número total de avaliações de clientes para 2018, 2019 e 2020.
• Obtenha o número total de avaliações de clientes para o ano de 2019.
• Obtenha o número total de avaliações de clientes para janeiro de 2020.

Solução não filtrada

Vamos supor que já existe um link externo disponível chamado myLink (consulte Conjuntos de dados externos: Acessando o AWS S3 no Couchbase Analytics para ver um exemplo de como um link é criado). Começamos criando uma coleção externa do Analytics para todos os dados de revisão sem prefixo e sem filtros de inclusão/exclusão. A sintaxe é simples:

Com essa coleção externa do Analytics criada, vamos escrever as consultas, que são simples e diretas, como segue:

Considerando nossa largura de banda de Internet e a distância do provedor de serviços, poderíamos obter (e de fato obtivemos) o seguinte:

• Essas consultas levaram 435, 448 e 430 segundos para terminar, o que mostra que eles tiveram quase o mesmo desempenho.
• Cada consulta resultou em 720 GB de transferência de dados.

O que está acontecendo aqui é que cada uma dessas consultas resultou na leitura de cada registro de dados (ou seja, todos os dados são transferidos) e, em seguida, na aplicação de qualquer filtragem necessária para fornecer o resultado correto. Entretanto, os dados já foram transferidos no momento em que foram filtrados. Esse é o principal fator determinante do desempenho no exemplo acima.

Na ausência de outras otimizações, todas as consultas às nossas análises lerão todo o conjunto de dados repetidas vezes, o que pode ser muito caro. Embora isso possa ser aceitável para dados externos acessados com pouca frequência, podemos fazer (muito) melhor, se desejarmos.

Solução filtrada

Agora, vamos examinar como podemos utilizar o prefixo e Incluir/excluir filtros disponíveis para coleções externas do Analytics e como estruturamos nossos dados para melhorar o desempenho de nossas consultas.

A primeira consulta exige a leitura de todos os dados, portanto, vamos deixá-la como está. Em vez disso, vamos examinar as consultas 2 e 3.

Na consulta 2, os dados necessários são apenas para o ano de 2019, portanto, podemos criar uma nova coleção externa do Analytics e usar o ano como prefixo ao fazer isso:

O DDL resulta em uma coleção externa do Analytics configurada para ler os dados somente do prefixo especificado, ou seja, "revisões/2019". É importante observar que essa coleção é virtualÉ apenas outro ponto de entrada nomeado para os mesmos dados armazenados externamente. (Nenhum dado está sendo replicado e nenhum espaço adicional está sendo usado devido à criação dessa coleção externa adicional - são apenas metadados).

Para entender o que está acontecendo, vamos ver o que acontece internamente. Quando uma coleção externa do Analytics é consultada, o mecanismo de consulta começa recuperando os metadados dos arquivos, que contêm apenas informações sobre os arquivos. O conteúdo dos arquivos ainda não é lido. Parte das informações de metadados retornadas é o nome completo/caminho dos arquivos e os tamanhos de seu conteúdo.

O Analytics utiliza essas informações para executar duas etapas:

• Ele aplica qualquer filtragem de prefixo, inclusão/exclusão no nome do arquivo, para decidir se deve incluir cada arquivo ou excluí-lo completamente, economizando assim recursos.
• Ele calcula o tamanho geral dos dados, o que leva à distribuição uniforme da carga de trabalho entre todas as partições dos nós do Analytics para acesso e processamento paralelos.

Aplicando o exposto acima, as consultas no my2019Collection só lerá os arquivos prefixados com "revisões/2019", que incluirá apenas 33% dos dados. A consulta relevante agora pode ser escrita como:

Executando a consulta acima, observamos o seguinte:

• O tempo total de execução é agora de 160 segundos, abaixo dos 448 segundos anteriores, apenas 35% do tempo original. Isso é esperado, pois lemos apenas 33% dos dados.
• A quantidade total de dados transferidos é de 240 GB, abaixo dos 720 GB anteriores.

Isso representa uma melhoria considerável no desempenho e na utilização de recursos.

Seguindo o mesmo padrão, vamos usar o recurso de filtro include/exclude de coleções externas. A Consulta 3 está interessada apenas nos dados de janeiro de 2020.

Vamos criar uma coleção externa apropriada do Analytics da seguinte forma:

Quando os dados forem lidos da coleção acima, eles incluirão apenas os arquivos prefixados com "avaliações/2020", incluindo efetivamente apenas os dados de 2020 e, em seguida (também antes de ler os dados!), o Analytics também aplicará o filtro de inclusão. Como resultado, a consulta só recuperará arquivos que correspondam ao padrão "*/Jan/*.json" e, portanto, incluirá apenas arquivos JSON para janeiro. Depois de determinar os arquivos de destino para a consulta, o mecanismo de consulta distribuirá a carga de trabalho entre as partições e começará a ler os dados.

Executando nossa terceira consulta, escrita com base nessa nova coleção:

Observamos o seguinte:

• O tempo total de execução agora é de apenas 12 segundos, pois estamos lendo efetivamente apenas 2,78% dos dados.
• A quantidade total de dados transferidos agora é de apenas 20 GB.

Observe que os filtros include/exclude também podem suportar expressões curinga, e vários filtros podem ser especificados ao mesmo tempo, por exemplo:

Isso pode ser usado para incluir os dados apenas de janeiro e março.

Próximas etapas

Como o acesso a dados externos pode ser dispendioso, é recomendável aplicar as práticas recomendadas de organização de dados e as definições de coleções externas correspondentes. Isso ajudará muito a obter o melhor desempenho possível, permitindo que o Couchbase Analytics utilize os recursos disponíveis em paralelo o máximo possível e mantenha os custos envolvidos na execução de consultas em um nível mínimo.

Acompanhe os seguintes links usados neste artigo para saber mais sobre o Couchbase Analytics:

• Descobrir como os clientes usam o Couchbase Analytics neste artigo.
• Uso de coleções do Analytics com AWS S3 e Armazenamento de Blobs do Azure.
• Uso de vários discos para acelerar as consultas do Couchbase Analytics
• JSON Analytics - NoETL com NoSQL e Couchbase
• Usando SQL++ para análise (SQL para JSON)