Analytics - Ame o modelo de médico com o qual você está

Nos aplicativos de negócios, os dados geralmente são modelados para um grande número de consultas simultâneas de baixa latência. Entretanto, se você quiser obter insights observando as tendências, acabará desejando ter um modelo de dados totalmente diferente. O meio tradicional de fazer a quadratura desse círculo era mover, transformar e carregar os dados em outro lugar, mas isso introduz sua própria série de problemas, incluindo latência inaceitável, várias fontes de verdade e muitas despesas.

Os clientes do Couchbase sabem que o serviço Analytics oferece uma maneira fácil de lidar com relatórios analíticos e de tendências em tempo real sobre os dados que eles têm em produção no momento. Um exemplo disso surgiu recentemente, quando trabalhamos com um cliente que buscava identificar a atividade de clientes de alto nível associada a um programa de fidelidade de parceiros corporativos. O modelo de documento subjacente foi claramente projetado tendo em mente o aplicativo interativo, e não a geração de relatórios. (Isso não é incomum, como você deve saber por experiência própria.) Vamos dar uma olhada rápida no problema e em como o resolvemos.

Exemplo de documento

No nosso caso, o modelo de documento (que dá suporte a um aplicativo de reservas on-line) é composto de quatro seções. A primeira seção inclui identificadores básicos de documentos e aplicativos. A segunda descreve as informações de reserva sobre uma excursão. A terceira contém detalhes sobre um ou mais itinerários associados à reserva, juntamente com os requisitos dos passageiros para um ou mais passageiros. A seção final descreve os programas de fidelidade corporativos aos quais cada um dos passageiros pode pertencer.

Elementos de consulta

Para concluir a análise, meu cliente precisou extrair ou filtrar os seguintes campos:

• status, equipamento, embarque (convertido em formato legível por humanos), linha, _type, daysOnboard, passengerNumber, loyaltyId, partnerId

O problema, é claro, é que esses campos existem em níveis hierárquicos totalmente diferentes dentro do modelo de documento. Alguns são valores escalares, prontamente acessíveis a partir de uma simples consulta:

• status, equipamento, embarque, linha, _tipo

Outro é um elemento dentro de uma matriz (composta de itinerários de viagem), que deve ser aninhado:

• dias a bordo

Dentro dessa mesma matriz há uma segunda matriz (composta de detalhes do passageiro), cujo elemento deve ser usado como uma chave de junção:

• passengerNumber

Essa chave de junção é usada para acessar elementos de uma terceira matriz, que, por motivos de aplicativos comerciais, não está aninhada na segunda:

• loyaltyId, partnerId

Esses diferentes níveis equivalem a diferentes caminhos de acesso, o que aumenta a complexidade da análise. Felizmente, o N1QL for Analytics fornece as ferramentas sintáticas de que precisamos. Veja abaixo uma descrição passo a passo do processo que você pode usar para criar sua consulta.

Etapa 1 - seleção simples de um elemento escalar

Essa etapa deve ser bastante clara para pessoas com experiência em SQL. Usamos uma instrução select para recuperar um valor escalar do bucket de linhas. Qualificamos o campo de status como parte da seção de reserva e limitamos o número de registros a serem retornados.

Resultados da consulta:

Etapa 2 - Unnest e adicionar elemento da primeira matriz

Em seguida, adicionamos dados da seção de itinerário do documento. No entanto, como esses elementos estão incorporados em uma matriz, primeiro precisamos aninhá-los.

Resultados da consulta:

Etapa 3 - Unnest e adicionar elemento da segunda matriz (dentro da primeira)

Agora adicionamos elementos da matriz de passageiros incorporada. (Observe que aumentamos nosso limite para garantir que realmente estamos acessando mais de um elemento da matriz).

Resultados da consulta:

Etapa 4 - Unnest e adicionar elemento da terceira matriz, acessível por meio de junção

Os elementos do terceiro array (passengerDetails) devem ser aninhados e vinculados aos elementos do array passengers acima. Fazemos isso por meio da cláusula where.

Resultados da consulta:

Etapa 5 - Adicionar os elementos de consulta restantes

Outros campos são necessários para completar a consulta. Observe especialmente o campo _type adicionado à cláusula where. É muito provável que, em um sistema de produção, um bucket contenha documentos de vários tipos. Os resultados da consulta podem ser filtrados na própria consulta (como no exemplo abaixo) ou como parte da criação do conjunto de dados do Analytics.

Resultados da consulta:

Leitura adicional

O Unnest é um recurso avançado do N1QL for Analytics, que fornece os meios para dominar vários elementos incorporados em seus dados. Mais informações sobre sua sintaxe podem ser encontradas aqui: https://docs.couchbase.com/server/6.0/analytics/3_query.html#Unnest_clauses

Um guia completo do N1QL for Analytics - tenho orgulho de possuir uma cópia assinada dele - pode ser encontrado aqui: https://www.amazon.com/SQL-Users-Tutorial-Don-Chamberlin/dp/0692184503/

Experimente você mesmo

Vá direto para https://docs.couchbase.com/server/6.0/analytics/quick-start.html#Using_docker e comece a usar imediatamente com um tutorial baseado no Docker. Ou, se preferir, faça o download do Couchbase Server 6 Enterprise nesta página: https://www.couchbase.com/downloads