Navegando pela Análise de Dados na Era NoSQL

Os sistemas de banco de dados NoSQL firmaram sua presença por mais de uma década, conquistando uma fatia substancial de mercado no domínio de bancos de dados OLTP. A rápida adoção de bancos de dados NoSQL para casos de uso de OLTP pode ser atribuída a fatores-chave como escalabilidade e disponibilidade, juntamente com um suporte robusto ao desenvolvimento ágil por meio de design de esquema flexível e desempenho aprimorado.

A pedra angular das práticas de desenvolvimento ágil para desenvolvedores de aplicativos modernos reside na flexibilidade oferecida por um modelo de documentos, permitindo uma rápida adaptação às necessidades de negócios em evolução. Isso efetivamente liberou os desenvolvedores da dependência de administradores de banco de dados, eliminando gargalos e a necessidade de aderir às janelas de alteração de banco de dados corporativos.

Vamos considerar um aplicativo de biblioteca de exemplo que possui um JSON Schema

A introdução do gênero de um livro em nosso aplicativo de biblioteca é uma tarefa simples para o desenvolvedor do aplicativo. Isso envolve um ajuste simples: adicionar um novo campo de array chamado gênero ao documento. Como um livro pode pertencer a vários gêneros, essa abordagem flexível acomoda a natureza dinâmica da categorização de livros sem esforço.

O ciclo de vida dos dados culmina com uma aplicação OLTP? A resposta inequívoca é não.

Muitos aplicativos OLTP fluem perfeitamente para sistemas analíticos a jusante, como análises em tempo real, data marts, data warehouses ou data lakes. No entanto, surge um desafio significativo porque a maioria dos sistemas de bancos de dados analíticos em todo o mundo é construída sobre modelos de bancos de dados relacionais, esperando um formato tabular, relacional e fixo para os dados armazenados. 

Eis que surge um dilema notável: embora os sistemas de banco de dados NoSQL OLTP a montante ostentem um esquema flexível com um modelo de documentos — onde cada documento pode possuir um esquema distinto e os documentos podem encapsular documentos aninhados ou matrizes —, converter essa diversidade de dados de volta para o mundo relacional induz a desafios consideráveis de ETL (Extração, Transformação e Carga). Contudo, o problema vai além dos desafios de ETL por si só. 

A flexibilidade do esquema e o suporte ao modelo de documentos em aplicações OLTP significam que os desenvolvedores não estão mais vinculados a coordenar alterações de banco de dados com um Administrador de Banco de Dados (DBA), o que leva a uma evolução rápida e dinâmica do esquema da aplicação. Em contraste, os sistemas downstream, inerentemente relacionais por natureza, lutam para acompanhar o ritmo da evolução constante do esquema. Para ilustrar esse problema, vamos revisitar nosso exemplo da aplicação de biblioteca.

Supondo que este aplicativo de biblioteca tenha um banco de dados analítico relacional subjacente, o esquema seria mais ou menos assim.

Reservar mesa

id_do_livro	título	autor
1	O Grande Gatsby	F. Scott Fitzgerald

Tabela de Editoras

id_do_editor	nome	ano
1	Scribner	1925
2	Livros Vintage	1995

Tabela Book_Publisher

id_do_livro	id_do_editor
1	1
1	2

Se precisarmos transmitir a adição direta do gênero campo nos documentos do banco de dados NoSQL OLTP para o sistema de análise downstream, o processo envolve o seguinte.

Nós introduziríamos 2 novas tabelas: Gênero e Gênero Literário.

Tabela de Gêneros

id_do_genero	nome
1	Ficção
2	Clássico

Tabela Book_Genre

id_do_livro	id_do_genero
1	1
1	2

Além disso, a aplicação de ETL responsável por fornecer dados ao sistema analítico relacional deve assumir a tarefa de decompor o gênero matriz dentro de cada documento e populando as informações resultantes nas tabelas correspondentes para cada documento.

A partir dos exemplos fornecidos acima, é evidente que a construção de aplicações analíticas em tempo real e a sincronização com as mudanças dinâmicas em bancos de dados OLTP NoSQL upstream representam desafios para os sistemas analíticos relacionais. Apesar desses desafios, por que as empresas persistem em construir sistemas analíticos relacionais, especialmente quando os sistemas OLTP upstream tendem a ter uma natureza orientada a documentos NoSQL? Para aprofundar nisso, vamos explorar os princípios fundamentais que sustentam os sistemas de banco de dados projetados para análises.

Consultas analíticas frequentemente envolvem o manuseio de grandes conjuntos de dados com junções complexas, agregações e várias camadas de filtragem. Muitas dessas operações podem ser significativamente aceleradas executando-as em paralelo através de uma rede de servidores. Isso exige que os sistemas de banco de dados projetados para análises possuam robustez Processamento Paralelo Massivo capacidades, permitindo a distribuição de um plano de consulta entre múltiplos servidores físicos para melhorar a velocidade de execução da consulta.

Consultas analíticas comumente focam em recuperar um subconjunto específico de colunas de todo o conjunto de dados. Portanto, Bancos de dados colunares são favorecidos em casos de uso analíticos porque otimizam as operações de E/S. Ao buscar seletivamente apenas as colunas relevantes para uma consulta, esses bancos de dados minimizam a necessidade de recuperar todas as informações de colunas do disco, resultando em um desempenho de consulta mais eficiente.

Consultas analíticas são inerentemente complexas e podem produzir múltiplos planos de execução potenciais. No reino dos sistemas de banco de dados para análise, é primordial que esses sistemas vão além do planejamento baseado em regras e empreguem um Otimizador de Consultas Baseado em Custos. Este otimizador desempenha um papel crucial na identificação do plano de consulta mais eficiente, considerando uma série de fatores de custo, garantindo a execução ideal de consultas analíticas complexas.

bancos de dados analíticos são projetados para escalabilidade horizontal, permitindo a adição contínua de recursos de computação a um cluster de banco de dados existente. Essa escalabilidade serve para reduzir o tempo de execução de consultas e acomodar consultas adicionais. Particularmente em ambientes em nuvem, onde a rápida adição e remoção de recursos de computação é viável, torna-se imperativo adotar uma arquitetura de banco de dados analítico que enfatize Separação de Armazenamento e Computação. Este design facilita a expansão ou contração rápida do cluster de banco de dados, garantindo adaptabilidade a cargas de trabalho variáveis.

Historicamente, os bancos de dados orientados a documentos NoSQL não atendiam aos quatro princípios essenciais mencionados acima exigidos por sistemas de bancos de dados analíticos. Consequentemente, as empresas persistiram na utilização de bancos de dados relacionais para sistemas analíticos, mesmo quando o banco de dados OLTP de origem adotava uma abordagem NoSQL. Essa decisão foi impulsionada pelas limitações descritas anteriormente.

Couchbase Analytics para o resgate!

O Couchbase Analytics destaca-se como um Serviço em Nuvem de Banco de Dados Colunar Massivamente Paralelo, orientado a documentos NoSQL, com separação de Armazenamento e Computação, equipado com um Otimizador Baseado em Custo integrado. Atendendo a todos os princípios cruciais de um banco de dados analítico de alto desempenho, o Couchbase Analytics preserva o amado modelo de dados flexível orientado a documentos. Capacitando empresas a construírem sistemas analíticos em tempo real, ele reduz significativamente o esforço de ETL e o tempo necessário para ingerir dados de bancos de dados OLTP NoSQL de origem. Além disso, garante que as aplicações analíticas permaneçam sincronizadas com os dados de negócios mais recentes provenientes dos sistemas transacionais de origem.

Saiba mais sobre como o Couchbase Analytics atende às suas necessidades:

• Ler Couchbase Analytics adiciona Serviço de Dados em Tempo Real
• Assista Couchbase Anuncia Novo Serviço de Análise