Navegando pela análise na era NoSQL

Os sistemas de banco de dados NoSQL estabeleceram firmemente sua presença por mais de uma década, conquistando uma participação de mercado substancial no domínio de banco 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 importantes, como escalabilidade e disponibilidade, juntamente com um suporte robusto para o desenvolvimento ágil por meio de um design de esquema flexível e desempenho aprimorado.

A pedra angular das práticas de desenvolvimento ágil para os desenvolvedores de aplicativos modernos está na flexibilidade oferecida por um modelo de documento, que permite uma adaptação rápida aos requisitos comerciais em evolução. Isso liberou efetivamente os desenvolvedores da dependência dos administradores de banco de dados, eliminando gargalos e a necessidade de aderir às janelas de alteração do banco de dados corporativo.

Vamos considerar um aplicativo de biblioteca de amostra com um esquema JSON

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

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

Muitos aplicativos OLTP fluem sem problemas para sistemas analíticos downstream, como análise em tempo real, data marts, data warehouses ou data lakes. No entanto, um desafio significativo surge porque a maioria dos sistemas de bancos de dados analíticos em todo o mundo é construída com base em modelos de bancos de dados relacionais, que esperam um formato fixo, tabular e relacional para os dados armazenados. 

Aqui reside um problema digno de nota: embora os sistemas de banco de dados OLTP NoSQL upstream apresentem um esquema flexível com um modelo de documento - em que cada documento pode ter um esquema distinto e os documentos podem encapsular documentos ou matrizes aninhados -, a conversão desses dados diversos de volta para o mundo relacional induz a desafios consideráveis de ETL (Extract, Transform, Load). No entanto, o problema vai além dos desafios de ETL. 

A flexibilidade do suporte a esquemas e modelos de documentos em aplicativos OLTP significa que os desenvolvedores não precisam mais coordenar as alterações no 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 do aplicativo. Em contrapartida, os sistemas downstream, inerentemente relacionais por natureza, têm dificuldade para acompanhar a evolução constante do esquema. Para ilustrar esse problema, vamos rever nosso exemplo do aplicativo de biblioteca.

Supondo que esse aplicativo de biblioteca tenha um banco de dados analítico relacional subjacente, o esquema seria parecido com o seguinte.

Mesa de livros

Mesa do editor

Tabela Book_Publisher

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

Introduziríamos duas novas tabelas: Gênero e Gênero de livro.

Tabela de gêneros

Tabela Book_Genre

Além disso, o aplicativo ETL responsável pelo fornecimento de dados ao sistema analítico relacional deve realizar a tarefa de decompor os dados em uma única tabela. gênero em cada documento e preenchendo as informações resultantes nas tabelas correspondentes de cada documento.

Com base nos exemplos fornecidos acima, fica evidente que a criação de aplicativos analíticos em tempo real e a sincronização com as alterações dinâmicas nos bancos de dados OLTP NoSQL upstream representam desafios para os sistemas analíticos relacionais. Apesar desses desafios, por que as empresas persistem em criar sistemas analíticos relacionais, especialmente quando os sistemas OLTP upstream se inclinam para uma natureza orientada a documentos NoSQL? Para nos aprofundarmos no assunto, vamos explorar os princípios fundamentais que sustentam os sistemas de banco de dados projetados para análise.

As consultas analíticas geralmente envolvem a manipulação de conjuntos de dados extensos com junções complexas, agregações e várias camadas de filtragem. Muitas dessas operações podem ser significativamente agilizadas ao serem executadas em paralelo em uma rede de servidores. Isso exige que os sistemas de banco de dados projetados para análise possuam Processamento paralelo maciço permitindo a distribuição de um plano de consulta em vários servidores físicos para aumentar a velocidade de execução da consulta.

As consultas analíticas geralmente se concentram na recuperação de um subconjunto específico de colunas de todo o conjunto de dados. Portanto, Bancos de dados orientados por colunas são favorecidos em casos de uso analítico 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 da coluna do disco, resultando em um desempenho mais eficiente da consulta.

As consultas analíticas são intrincadas por natureza e podem gerar vários planos de execução em potencial. No âmbito dos sistemas de banco de dados para análise, é fundamental que esses sistemas vão além do planejamento baseado em regras e empreguem um Otimizador de consultas com base em custos. Esse otimizador desempenha um papel fundamental 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.

Os 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. Esse dimensionamento serve para reduzir os tempos de execução das consultas e acomodar consultas adicionais. Especialmente em ambientes de 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íticos que enfatize Separação entre armazenamento e computação. Esse design facilita o dimensionamento ou a contração rápida do cluster do banco de dados, garantindo a adaptabilidade a cargas de trabalho variáveis.

Historicamente, os bancos de dados orientados a documentos NoSQL não atendiam aos quatro princípios essenciais acima exigidos pelos sistemas de bancos de dados analíticos. Consequentemente, as empresas persistiam em utilizar bancos de dados relacionais para sistemas analíticos, mesmo quando o banco de dados OLTP upstream adotava uma abordagem NoSQL. Essa decisão foi motivada pelas limitações descritas anteriormente.

Couchbase Analytics to the rescue!

Couchbase Analytics stands as a NoSQL Document-oriented, Storage-Compute Separated, Massively Parallel Columnar Database Cloud Service equipped with an integrated Cost-Based Optimizer. Addressing all the crucial principles of a high-performance analytical database, Couchbase Analytics preserves the beloved Flexible Document-Oriented data model. Empowering enterprises to construct real-time analytical systems, it significantly reduces the ETL effort and time required for ingesting data from upstream NoSQL OLTP databases. Moreover, it ensures that analytical applications stay synchronized with the most recent business data arriving from upstream transactional systems.

Learn more about how Couchbase Analytics addresses your needs:

• Ler Couchbase Analytics Adds Real-time Data Service
• Assista Couchbase Announces New Analytics Service