Quando você precisa consultar documentos usando SQL, há duas opções disponíveis no Couchbase. A opção Serviço de consulta e o Serviço de análise. Nosso blog, N1QL: Consultar ou analisar? fornece uma visão geral detalhada de ambos os serviços. É altamente recomendável lê-lo antes deste artigo. Este artigo tem o objetivo de expandir o blog anterior, acrescentando alguns exemplos práticos e concretos. Para cada exemplo, abordaremos como escrever a consulta em ambos os serviços e analisaremos as diferenças de desempenho. O objetivo é que os leitores saiam com mais conhecimento para ajudar a identificar rapidamente os padrões e os casos de uso mais adequados a cada serviço.
Resumo
Antes de começarmos com os exemplos. Vamos nos atualizar sobre as principais características de alto nível dos dois serviços.
Serviço de consulta |
Serviço de análise |
| Usado para manipulação de dados dentro da lógica do aplicativo. | Usado para relatórios, análises (históricas, interativas) e painéis de controle. |
| Mais eficiente para consultas curtas e operacionais que recuperam ou manipulam pequenas quantidades de dados. | Mais eficiente para consultas mais longas, complexas e ad-hoc que normalmente recuperam e processam grandes quantidades de dados. |
| Oferece suporte a operações SELECT, INSERT, UPDATE, DELETE e MERGE. | Oferece suporte apenas a operações SELECT. |
Veja https://www.couchbase.com/blog/n1ql-to-query-or-to-analyze/ para obter uma tabela completa.
Configuração
Para este tutorial, usaremos o Couchbase 6.5 e os dados de amostra fornecidos na interface de usuário de administração do Couchbase. Meu ambiente é um cluster de 3 nós do Couchbase 6.5 com 1536 MB alocados para o serviço Analytics. Todas as outras configurações são as padrão. Se você não tiver acesso a um cluster, poderá executar rapidamente o Couchbase 6.5 em um contêiner do Docker executando o seguinte comando:
|
1 |
doca executar -d --nome db -p 8091-8096:8091-8096 -p 11210-11211:11210-11211 couchbase:empresa-6.5.0 |
Se estiver seguindo a rota do Docker, acesse http://localhost:8091 no navegador após o início do contêiner e configure a instância do Couchbase usando as opções padrão em cada etapa. Não importa o nome que você dá à sua instância do Couchbase.
Isenção de responsabilidade sobre o desempenho
Analisaremos os tempos de resposta dos exemplos a seguir. É importante observar que o desempenho pode variar muito, dependendo de como o ambiente do Couchbase está configurado. No entanto, você ainda deve conseguir observar diferenças semelhantes entre os serviços Query e Analytics, independentemente do seu ambiente.
Instalar o balde de amostras de viagem
No painel de administração do Couchbase, navegue até Configurações -> Buckets de amostra. Instale o bucket Travel Sample (Amostra de viagem). A documentação detalhada sobre como fazer isso pode ser encontrada em nosso site de documentação.
Configuração do serviço de consulta
A instalação do Sample Bucket também cria os índices necessários. Isso significa que nenhuma configuração adicional é necessária para o Query Service.
Configuração do serviço de análise
Para o Analytics Service, precisamos preencher os conjuntos de dados para cada "tipo" de documento em nosso bucket. Navegue até o Analytics Workbench (http://localhost:8091/ui/index.html#!/cbas/workbench) e execute as seguintes consultas para criar os conjuntos de dados:
|
1 2 3 4 5 6 |
CRIAR CONJUNTO DE DADOS rotas ON `viagens-amostra` ONDE `tipo` = "route" (rota); CRIAR CONJUNTO DE DADOS marcos históricos ON `viagens-amostra` ONDE `tipo` = "marco"; CRIAR CONJUNTO DE DADOS hotéis ON `viagens-amostra` ONDE `tipo` = "hotel"; CRIAR CONJUNTO DE DADOS companhias aéreas ON `viagens-amostra` ONDE `tipo` = "companhia aérea"; CRIAR CONJUNTO DE DADOS aeroportos ON `viagens-amostra` ONDE `tipo` = "aeroporto"; CONECTAR LINK Local; |
Isso criará conjuntos de dados para rotas, pontos de referência, hotéis, companhias aéreas e aeroportos usando o bucket travel-sample. Por fim, a execução da instrução CONNECT começará a preencher cada um dos conjuntos de dados.
Nos exemplos a seguir, usaremos consultas N1QL simples. Para obter uma análise detalhada das diferenças de linguagem N1QL entre Query e Analytics, consulte a seção N1QL for Analytics vs. N1QL for Query página de referência em nossos documentos.
Caso de uso: Obter todas as rotas de LAX para SFO
Agora estamos prontos para escrever nossa primeira consulta. Para este caso de uso, queremos encontrar todas as rotas disponíveis para um determinado aeroporto de origem e destino.
Qual é o melhor serviço?
Essa é definitivamente uma consulta operacional que retornará uma quantidade limitada de dados. É uma consulta simples que não executa nenhuma agregação ou função complexa sobre nossos dados. Há apenas um filtro simples na origem e no destino. Portanto, o Query Service (http://localhost:8091/ui/index.html#!/query/workbench) é a escolha óbvia.
|
1 2 3 4 |
selecionar * de `viagens-amostra` onde tipo = "route" (rota) e aeroporto de origem = "LAX" e aeroporto de destino = "SFO" |
Desempenho: 4 milissegundos
Essa é uma consulta simples e também retorna apenas 7 documentos. Essa é uma consulta operacional típica que um aplicativo pode enviar ao Couchbase. O desempenho é rápido e consistente de forma confiável.
Equivalente ao serviço de análise
Para fins de demonstração, vamos criar a mesma consulta para o Analytics Service. O Analytics Service é um exagero para uma consulta simples como essa. Portanto, se estivéssemos criando um aplicativo para esse caso de uso, não escolheríamos o serviço Analytics. Esperaríamos que ele tivesse um desempenho inferior ao do Query Service.
|
1 2 3 |
selecionar * de rotas onde aeroporto de origem = "LAX" e aeroporto de destino = "SFO" |
Desempenho: ~36 milissegundos
Como você pode ver neste exemplo. O Query Service tem o melhor desempenho para esse caso de uso, como esperado. Sob carga pesada, esperamos que o Query Service tenha um desempenho ainda melhor do que a diferença de mais de 30 milissegundos que esse teste simples mostra.
Caso de uso: Obter as cidades com mais hotéis
Qual é o melhor serviço?
Para esse caso de uso, queremos descobrir o número de hotéis disponíveis em cada cidade e classificar os resultados pelas cidades com mais hotéis primeiro. Isso exigirá que examinemos todos os nossos hotéis e coletemos as contagens por país e cidade e depois as classifiquemos. Seguindo a lógica que definimos no início, o Analytics Service (http://localhost:8091/ui/index.html#!/cbas/workbench) deve ter um desempenho melhor para esse caso de uso. Vamos testar essa teoria.
|
1 2 3 4 5 6 7 |
selecionar país, cidade, contagem(id) de hotéis grupo por país, cidade ordem por contagem(id) desc |
Desempenho: ~36 milissegundos
É interessante notar que o desempenho dessa consulta é quase o mesmo do nosso exemplo anterior do Analytics (36 ms), embora a consulta anterior fosse muito mais simples e menor em termos computacionais. Isso nos diz que o desempenho da linha de base em meu ambiente de 3 nós pode estar em torno de 36 milissegundos para consultas do Analytics. Embora essa consulta seja mais complexa do que o nosso primeiro exemplo, ela ainda é relativamente simples para o serviço do Analytics.
Equivalente ao serviço de consulta
Vamos criar a mesma consulta para o Query Service. Em teoria, essa é uma consulta mais pesada do que o nosso exemplo anterior do Query Service. Ela também está processando e retornando muito mais dados do que o primeiro exemplo. Esperamos que o Query Service não tenha um desempenho tão bom quanto o Analytics Service.
|
1 2 3 4 5 6 7 8 |
selecionar país, cidade, contagem(id) de `viagens-amostra` onde tipo = "hotel" grupo por país, cidade ordem por contagem(id) desc |
Desempenho: ~90 milissegundos
Aqui temos uma divergência realmente grande no desempenho. Como esperado, o serviço Analytics é capaz de processar a consulta duas vezes mais rápido, em média, do que o serviço Query.
Caso de uso: Obter as companhias aéreas com mais rotas
Qual é o melhor serviço?
Essa consulta está fazendo uma pergunta semelhante à do nosso exemplo anterior. Mas a diferença aqui é que precisaremos de uma união, já que os dados da companhia aérea residem em um tipo de documento separado dos dados das rotas em nosso bucket. Esperamos que o Serviço de análise para ter um desempenho melhor com essa consulta, pois ela está fazendo uma agregação e um JOIN.
|
1 2 3 4 5 6 7 8 9 10 |
selecionar a.id, a.indicativo, a.nome, a.país, contagem(r.id) como route_count de companhias aéreas a unir-se rotas r em CONCAT("companhia aérea_", to_string(a.id)) = r.companhia aérea grupo por a.id, a.indicativo, a.nome, a.país ordem por route_count desc limite 100 |
Desempenho: 82 milissegundos
Aqui podemos ver que essa consulta está realmente começando a pressionar um pouco o serviço do Analytics. Nossa primeira consulta do Analytics levou 36 milissegundos em média e esta está aumentando para 82 milissegundos. A principal diferença com essa consulta é a adição de um JOIN.
Equivalente ao serviço de consulta
Lembre-se de que, no início, criamos "conjuntos de dados" analíticos separados para cada tipo de documento nos dados da amostra de viagem. Cada Dataset funciona como sua própria tabela. Portanto, uni-los em uma consulta é simples se você já tiver escrito uniões SQL antes. O Query Service não tem nenhum conceito de "Datasets" da mesma forma que o Analytics Service. Portanto, temos que escrever a consulta de forma um pouco diferente para levar em conta todos os dados que residem no mesmo bucket. Precisamos unir documentos do tipo = "airline" a documentos do tipo = "route". Precisamos de uma subconsulta para fazer isso.
|
1 2 3 4 5 6 7 8 9 10 11 |
selecionar a.id, a.indicativo, a.nome, a.país, contagem(r.id) como route_count de `viagens-amostra` a unir-se (selecionar id, companhia aérea de `viagens-amostra` onde tipo = "route" (rota)) r em CONCAT("companhia aérea_", to_string(a.id)) = r.companhia aérea onde a.tipo = "companhia aérea" grupo por a.id, a.indicativo, a.nome, a.país ordem por route_count desc limite 100 |
Desempenho: 2 segundos
O desempenho do Analytics Service é drasticamente melhor para esse caso de uso devido ao JOIN. Outro benefício adicional do Analytics Service para esse caso é que escrever o JOIN é mais simples, pois não precisamos criar uma subconsulta para fazer a junção.
Caso de uso: Obter a classificação percentual das companhias aéreas com o maior número de rotas
Qual é o melhor serviço?
Este exemplo se baseia no anterior, acrescentando a classificação percentil das contagens de rotas. Esperamos que o desempenho seja melhor com Análises já que estamos adicionando ainda mais complexidade e computação à consulta. Vamos ver o impacto da adição de uma função Window à nossa consulta.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
selecionar a.id, a.indicativo, a.nome, a.país, contagem(r.id) como route_count, PERCENT_RANK() SOBRE ( ORDEM BY contagem(r.id) ) AS `classificação` de companhias aéreas a unir-se rotas r em CONCAT("companhia aérea_", to_string(a.id)) = r.companhia aérea grupo por a.id, a.indicativo, a.nome, a.país ordem por route_count desc limite 100 |
Desempenho: 85 milissegundos
Adicionar uma função Window não foi nada difícil para o serviço do Analytics, pois mal conseguimos ver uma diferença de desempenho.
Equivalente ao serviço de consulta
|
1 2 3 4 5 6 7 8 9 10 11 12 |
selecionar a.id, a.indicativo, a.nome, a.país, contagem(r.id) como route_count, PERCENT_RANK() SOBRE ( ORDEM BY contagem(r.id) ) AS `classificação` de `viagens-amostra` a unir-se (selecionar id, companhia aérea de `viagens-amostra` onde tipo = "route" (rota)) r em CONCAT("companhia aérea_", to_string(a.id)) = r.companhia aérea onde a.tipo = "companhia aérea grupo por a.id, a.indicativo, a.nome, a.país ordem por route_count desc limite 100 |
Desempenho: 2 segundos
Quando adicionamos a função Window à nossa consulta do serviço Query, também não conseguimos detectar um impacto no desempenho. A principal conclusão que podemos inferir desses resultados é que o JOIN é o maior fator de desempenho e a agregação (COUNT, nesse caso) é o segundo maior.
Conclusão
Esperamos que este artigo tenha ajudado você a entender melhor as duas opções de SQL no Couchbase e quando aplicá-las. Não deixe de conferir os seguintes recursos sobre Query e Analytics.
- Blog: N1QL: Consultar ou analisar?
- Referência de idioma: N1QL for Analytics vs. N1QL for Query
- Documentação: Introdução ao Analytics
- Documentação: Fundamentos da consulta
