As organizações que desejam aproveitar os muitos benefícios dos bancos de dados de documentos NoSQL geralmente se deparam com dois desafios:
- Como converter seus esquemas de RDBMS para aproveitar o modelo de documento sem esquema.
- Aprenda uma nova API/Query para acessar os dados.
Algumas pessoas também se confundem com o nome NoSQL. A abreviação significa "Not only SQL" (Não apenas SQL), mas também pode ser mal interpretada como "No to SQL" (Não ao SQL), aceitando assim que, para usar um Banco de dados NoSQLSe o banco de dados NoSQL for selecionado, as organizações não só terão que converter seu modelo de dados relacional em um modelo de documento, mas também receberão treinamento sobre as APIs do banco de dados NoSQL que selecionarão.
Na realidade, o setor de bancos de dados NoSQL nunca abandonou o acesso a dados mais popular para bancos de dados. Muitos fornecedores de NoSQL ainda estão usando uma variação do SQL. Cosmos DB, Cassandra CQL, Elasticsearch SQL, Laboratórios Cockroach. Mesmo com Consulta ao Mongodb você verá que ela se baseia na construção select-join-project, que é a base da álgebra relacional usada no SQL.
Uma empresa de banco de dados no espaço NoSQL que abordou totalmente essa questão da linguagem de consulta é a Couchbase. Embora o Couchbase armazene os dados no formato JSON nativo, o modelo de dados que ele suporta pode ser uma estrutura relacional ou hierárquica, que é frequentemente usada no modelo baseado em documentos por sua flexibilidade e extensibilidade de esquema. Isso é possível porque o Couchbase fornece um SQL-linguagem de consulta semelhante à SQL - N1QL, que amplia a linguagem SQL para permitir que os usuários manipulem a natureza hierárquica do modelo de documento. Tudo isso é construído sobre o serviço de dados de alto desempenho do Couchbase com suas APIs de valor-chave.
As organizações que desejam garantir que seus investimentos em bancos de dados aproveitem os benefícios atualmente disponíveis com Tecnologia NoSQL devem ser observados:
- O suporte de dados estruturados e não estruturados
- Escalabilidade horizontal
- Evolução do esquema fácil de gerenciar
- Talvez a mais importante de todas seja a opção de escolha de fornecedor, além dos atuais fornecedores de RDBMS que dominaram o mercado de bancos de dados nas últimas três décadas.
Para ajudar os clientes em sua decisão, a Altoros - uma empresa que se concentra em ajudar as empresas a mudar de seu sistema de TI legado para o futuro - publicou um relatório para comparar a linguagem de consulta nos bancos de dados mais populares da atualidade. Ele optou por se concentrar em MySQL/SQL, Couchbase N1QLe Consulta ao MongoDB linguagens. Cada linguagem de consulta foi avaliada quanto às suas implementações para atender aos diferentes cenários de consulta usando as seguintes métricas.
- Simplicidade
- Legibilidade
- Expressividade
- Flexibilidade
- Disponibilidade de habilidades
- Linha de códigos
- O número de viagens do aplicativo para o servidor
Você pode obter mais detalhes sobre esse relatório no site Site da Altorose também está disponível aqui em o que está na coluna "Novo".
Todos os exemplos de consultas e despejos de banco de dados em linguagem NoSQL que podem ajudar a implementar e executar todos os cenários deste relatório podem ser encontrados neste repositório do GitHub.
A metodologia do relatório da Altoros
O objetivo do relatório é comparar as linguagens de consulta sob a perspectiva dos aplicativos RDBMS tradicionais. Para isso, foram selecionadas:
Um modo de aplicativo de gerenciamento de atividades, geralmente encontrado em muitos dos sistemas de CRM que gerenciam as atividades de vendas, serviços e marketing. A configuração do relatório inclui o modelo relacional e o modelo de documento que são usados pelo Couchbase e pelo MongoDB
Ele também usa um conjunto de cenários de consulta que a maioria dos usuários desses sistemas reconheceria.
| Cenário | Descrição |
| 1. Relatório de reunião de clientes | Para me preparar para as reuniões com clientes que participarei na próxima semana, quero obter uma lista de todos os clientes que participarão das reuniões e seus contatos. |
| 2. Relatório de território de vendas regional | Sou gerente regional de vendas do território de C-Suite Sellers. Quero obter todas as contas atribuídas a esse território e os membros da equipe de contas. |
| 3. Os 10 principais setores dos clientes | Determinar os 10 principais setores de nossos clientes com base nas atividades de vendas de 2018. |
| 4. Organizações de vendas | Quero saber quanto tempo gastamos conversando com as contas atribuídas ao meu território no terceiro trimestre do ano fiscal de 2019. |
| 5. Um relatório de atividade de vendas | Como o número de tarefas relacionadas a vendas mudou de um mês para outro durante o ano de 2018. |
| 6. Conjunto de habilidades da equipe de vendas | Uma análise dos conjuntos de habilidades/funções da equipe de vendas na organização de vendas atual |
| 7. Relatório de interações com clientes | Uma consulta para revisar todas as apresentações que realizamos com os clientes no CY19Q4 com métricas detalhadas sobre o tempo gasto para cada cliente e a eficácia da reunião. |
| 8. Analisar o sentimento das avaliações de hotéis | Chamada da API de linguagem natural do Google para classificar todas as avaliações com base na pontuação de sentimento |
| 9. Um relatório de pesquisa de texto para identificar reuniões de clientes | Identificar as contas de clientes e seus contatos relacionados, onde um determinado tópico foi discutido. Os critérios de pesquisa podem incluir as seguintes informações, parcial ou totalmente: um título de reunião, um intervalo de datas de reunião, detalhes de contato do cliente, detalhes de membros da equipe de vendas (participantes) e um nome de cliente. |
Para cada cenário, o relatório fornece as soluções correspondentes escritas em linguagem de consulta SQL, N1QL e MongoDB.
- O relatório fornece uma classificação para cada linguagem de consulta com base nos seguintes critérios.
- Simplicidade
- Legibilidade
- Expressividade
- Flexibilidade
- Disponibilidade de habilidades
- O relatório também tabula duas métricas adicionais para o número de linhas de código e o número de viagens cliente-servidor exigidas por cada linguagem de consulta em cada solução dos nove cenários.
Os resultados dos critérios de avaliação
A tabela abaixo é um resumo de todas as classificações de todos os cenários de consulta. Consulte o relatório para obter a avaliação individual de cada um dos cenários de consulta.
Usando o MySQL-SQL como ponto de referência, o relatório avalia o Couchbase N1QL e a linguagem de consulta do MongoDB com base em vários critérios.
Observações:
- A Altoros, que trabalhou com MongoDB, Cassandra e RedisLab, descobriu que o N1QL é muito semelhante ao SQL e, de forma consistente, deu a ele uma classificação mais favorável do que a linguagem de consulta do MongoDB.
- O código de amostra para o cenário #3 mostra que as três linguagens de consulta são relativamente semelhantes para os cenários de consulta simples e têm classificações de critérios de avaliação semelhantes.
O número de linhas de código
O gráfico mostra o número de linhas de código para cada consulta. Embora essa métrica possa estar sujeita a deturpações, pois todas as linguagens de consulta têm sua própria formatação recomendada, ela pode fornecer um guia simples sobre a complexidade envolvida.
Observações:
- A linguagem de consulta N1QL NoSQL tem aproximadamente o mesmo número de linhas de código que o SQL.
- A linguagem de consulta do MongoDB tem consistentemente mais linhas de código.
- Para o cenário #7, a equipe da Altoros teve que escrever 347 linhas para a linguagem de consulta do MongoDB, em comparação com 21 linhas do N1QL. Essa diferença reflete as limitações da linguagem de consulta do MongoDB para computar agregações complexas e expressões de tabela comuns (CTE) que o SQL, e agora o N1QL, sempre foram os principais pontos fortes da tecnologia de banco de dados relacional nas últimas décadas.
O número de viagens cliente-servidor
O gráfico mostra o número de viagens que o aplicativo precisa enviar ao servidor de banco de dados.
Observações:
- Na maioria dos cenários, o SQL/N1QL exige apenas um único envio de consulta ao servidor, enquanto a consulta do MongoDB exige várias viagens. Isso se deve à expressividade do SQL/N1QL, em que os desenvolvedores de aplicativos só precisam declarar a saída desejada, e cabe ao servidor processar e retornar os resultados.
- A falta de suporte à agregação complexa exige que o MongoDB execute seu cálculo em várias fases. Isso é semelhante à abordagem de subconsulta SQL padrão. A diferença aqui é que os conjuntos de resultados das subconsultas precisam ser mantidos nos aplicativos clientes, que são posteriormente passados para outra consulta.
Principais conclusões do relatório
