Encerrando de uma vez por todas o debate entre relacional e NoSQL

O Couchbase 7.0 é um marco importante para os bancos de dados.

Em a versão mais recenteEm sua versão mais recente, há mais de 33 inovações principais e 100 inovações menores, todas culminando em um produto que é inovador e, ao mesmo tempo, familiar para desenvolvedores e engenheiros de DevOps.

O que conseguimos com esta versão é que, pela primeira vez, você pode intercalar transações SQL completas com operações de alto desempenho e alta escala, tudo em um único banco de dados. Isso elimina a necessidade de os desenvolvedores escolherem um sistema para transações e outro para alta velocidade, baixa latência e dimensionamento.

Vou falar sobre apenas duas dessas inovações neste artigo. Nos próximos dias e semanas, você verá várias outras postagens de blog da nossa brilhante equipe técnica sobre os outros detalhes da versão 7.0 do Couchbase

O Couchbase 7.0 apresenta pela primeira vez transações SQL com várias instruções em um banco de dados de documentos com esquema flexível. Além disso, introduzimos o conceito de Escopos e coleções na versão 7.0.

Essas duas inovações - transações com várias declarações e organização de dados - oferecem os conceitos familiares de bancos de dados relacionais em um sistema NoSQL. Agora está mais fácil do que nunca para os desenvolvedores migrarem seus aplicativos monolíticos do passado para microsserviços modernos que atendem às demandas atuais e futuras das organizações empresariais.

As limitações dos bancos de dados relacionais

Do ponto de vista da evolução do banco de dados, havia duas grandes limitações impostas pelos sistemas de gerenciamento de banco de dados relacionais (RDBMS). Uma delas era a escala e a outra era a rigidez do esquema.

A natureza de escalonamento vertical dos sistemas relacionais criados nos anos 80 refletia a realidade da infraestrutura daquela época. As redes - até mesmo as LANs - eram escassas, muito menos as WANs e a Internet. Portanto, trazer uma rede para o meio da computação não era possível, a menos que você construísse toda a pilha de hardware e gerenciasse tudo de maneira proprietária.

Como resultado, os bancos de dados transacionais tornaram-se essencialmente bancos de dados de servidor único. Mas os bancos de dados modernos exigem sistemas de dimensionamento horizontal que expandem e reduzem o uso de hardware com base na utilização de recursos. Esse é um dos primeiros problemas que o NoSQL resolveu.

Bancos de dados NoSQL também proporcionou ao mundo flexibilidade de esquema, que é o principal motivo pelo qual esses sistemas são tão populares. Mas nós, como ecossistema tecnológico, esquecemos uma das lições mais importantes que 40 anos de pesquisa e inovação em bancos de dados nos ensinaram.

Essa foi a lição do SQL.

Os pontos fortes do SQL

Centenas de bancos de dados surgiram e desapareceram, cada um proclamando seu próprio paradigma de programação, mas somente o SQL resistiu ao teste do tempo.

O motivo dessa resistência é duplo: O primeiro é a matemática que sustenta o modelo relacional (conhecido como cálculo relacional) e o segundo é a simplicidade da linguagem de programação. A Structured Query Language (SQL) é funcional e tem como base o inglês.

Esses dois pontos fortes do SQL permitem que você expresse conceitos complexos da teoria de conjuntos em uma sintaxe que se aproxima da forma como você os expressaria em inglês e oculta todas as complexidades de programação e outras idiossincrasias de manipulação de dados no sistema de banco de dados. Essa simplicidade declarativa foi o que levou à popularidade dos bancos de dados relacionais e permitiu que as equipes de desenvolvedores criassem alguns dos aplicativos corporativos mais sofisticados dos últimos 40 anos.

Quando se tratou de desenvolver a versão 7.0 do Couchbase, não foi uma proposta fácil trazer esse cálculo relacional e a simplicidade de programação para um banco de dados de esquema flexível. Foi uma jornada de seis anos.

Com a linguagem de consulta N1QLNo N1QL, a maioria dos pontos fortes do SQL já está coberta. O N1QL oferece o "polegar opositor" dos sistemas relacionais - o JOIN - bem como subconsultas e funções de janela. É a equivalência sintática de bancos de dados relacionais em um banco de dados de documentos de esquema flexível.

Inovação #1: Transações SQL com várias instruções no N1QL

Ao longo dos anos, os documentos do Couchbase incluíram propriedades ACID. Essa oferta amadureceu de ACID de documento único (no Couchbase 2.0) para ACID distribuído de vários documentos (na versão 6.5) e O Couchbase agora oferece suporte a transações SQL de várias instruções na versão 7.0.

Essa é uma etapa importante na evolução dos bancos de dados modernos.

O modelo de dados de documento elimina a incompatibilidade de impedância entre os desenvolvedores de aplicativos, que pensam em termos de objetos, e os bancos de dados, que armazenam dados em termos de linhas e colunas.

Para o Couchbase, JSON é o modelo de dados. O JSON fornece objetos, hierarquia e matrizes. A linguagem de consulta N1QL e os mecanismos de consulta ajudam você a consultar, transformar e manipular JSON de forma declarativa. Não há necessidade de escrever pipelines longos que são difíceis de escrever e manter. Não há necessidade de otimizar manualmente. O N1QL é o SQL para JSON. Você escreve; o Couchbase otimiza.

O SQL tem muitas funções. É uma linguagem de consulta para relatórios, mas também é uma linguagem de consulta para processamento de transações. O Couchbase Server 7.0 agora fornece transações de várias declarações em N1QL e oferece Transações ACID assim como um RDBMS.

Transações distribuídas como essa já existem há algumas décadas. No entanto, elas nunca foram escalonadas, pois esbarravam no que é popularmente conhecido como problemas de bloqueio e obstrução.

O Couchbase é um banco de dados multimodelo e de acesso múltiplo. Você pode acessar e manipular o documento JSON por meio da API de valor-chave e da linguagem de consulta N1QL. Ao introduzir transações com vários extratos, nossa primeira etapa foi o suporte ao acesso a dados de valor-chave. Essa etapa foi incluída na versão 6.5 com uma arquitetura para transações de vários documentos, mas faltava um coordenador central.

A versão 7.0 amplia esse suporte para transações SQL de vários estados no N1QL. Isso exigiu uma abordagem nova, com patente pendente, que explora a arquitetura de scale-out e a concorrência otimista do Couchbase para implementar transações distribuídas.

A redução de escala é obtida evitando-se o coordenador central para cada transação. Os detalhes de cada transação são mantidos em vários registros de transações ativas e são usados pelo protocolo de confirmação. O protocolo de confirmação distribuído é executado em várias instâncias e em paralelo. Isso torna os sistemas mais dimensionáveis e econômicos.

Esta é a aparência de uma transação SQL com várias instruções em um banco de dados relacional tradicional:

Essa mesma transação funciona no Couchbase 7.0 sem nenhuma modificação.

Apoiamos INICIAR, COMPROMISSO, ROLLBACK e SAVEPOINT para controlar a transação. A semântica ACID, como atomicidade em nível de declaração e read-your-own-writes, é suportada para cada declaração DML em uma transação.

Essas transações com várias declarações são a primeira grande inovação a que me referi anteriormente. Essa inovação oferece aos desenvolvedores a proteção familiar de transações em um banco de dados que lida com todas as complexidades de um esquema flexível e distribuição elástica de dados.

Inovação #2: organização de dados

A outra grande inovação introduzida na versão 7.0 do Couchbase é a organização dos dados no banco de dados. É aqui que entram o Escopo e as Coleções.

Os RDBMSs têm banco de dados -> esquema -> tabela -> linhas -> colunas. Agora o Couchbase tem Bucket -> Escopo -> Coleção -> documentos -> campos. Com a introdução de escopos e coleções, há uma correspondência direta entre a ontologia de um banco de dados relacional tradicional e um banco de dados NoSQL.

Reunindo tudo isso

A combinação dessas duas inovações estabelece a equivalência com um sistema de banco de dados relacional, tanto no nível estrutural da organização de dados - com escopos e coleções - quanto na equivalência do nível funcional - transações com várias declarações.

Vamos dar uma olhada mais de perto no que essas duas inovações significam para uma única transação.

Um banco de dados com flexibilidade de esquema significa que você não precisa predefinir um esquema antes de armazenar dados nesse banco de dados. O Couchbase é um banco de dados JSON, portanto, desde que você armazene dados JSON, não precisa se preocupar em definir o esquema, pois o JSON é autodescritivo.

Todos nós sabemos que não existe um aplicativo sem esquema. A diferença com o NoSQL é que o banco de dados não impõe seu próprio esquema (modelo de dados) além do esquema (modelo de objeto) imposto e implícito pelo aplicativo. Como você pode imaginar, esse JSON nada mais é do que a parte de dados do objeto. A evolução do esquema nada mais é do que alterações no próprio JSON.

A introdução de Escopos e Coleções lhe dá a capacidade de atribuir nomes aos documentos JSON e organizá-los de maneira significativa. Por ser um banco de dados de esquema flexível, o Couchbase preserva a capacidade de criar, atualizar e modificar Escopos e Coleções, além de criar índices e outros artefatos de esquema associados. Além disso, ele permite mover dados entre coleções, lidar com dimensionamento de capacidade elástica e adicionar ou remover nós - tudo isso enquanto uma transação está em andamento.

Em outras palavras, a semântica ACID é garantida, apesar de toda essa movimentação de dados, da reorganização física à lógica em todo o cluster. Você não precisa fazer nenhuma estruturação administrativa específica dos dados em nós ou fragmentos apropriados para que isso funcione. Quando você emite uma transação SQL com várias instruções, o Couchbase é projetado precisamente para lidar com essa fluidez de movimentação de dados sob a superfície.

Essa é a flexibilidade que o movimento NoSQL prometeu. Ela só não foi totalmente concretizada até agora.

Os bancos de dados relacionais tradicionais fazem com que você pague o preço total do ACID para cada operação no banco de dados. Os RDBMS foram criados em uma época em que os aplicativos iam para o banco de dados apenas para aplicativos transacionais do tipo livro-razão, executados em um mainframe com um número limitado de usuários.

Essa abordagem full-ACID se mostrou tão cara para os aplicativos atuais que, nos últimos 10 anos, os arquitetos de soluções tiveram que escolher no início do projeto de um novo microsserviço: Esse microsserviço exige semântica transacional? Se sim, então use um banco de dados relacional. Se não, graças a Deus, podemos usar um banco de dados escalonável, com desempenho e baixa latência, no qual podemos desenvolver rapidamente e escalonar com facilidade. Essa escolha, que precisava ser feita no início de cada novo projeto, aplicativo ou microsserviço, gerava frustração no desenvolvedor, expansão do banco de dados, inconsistência de dados, insegurança de dados e problemas de governança de dados.

Esse dilema agora faz parte dos livros de história.

Agora, o que você vai construir?

Os desenvolvedores agora podem usar um único banco de dados para obter escala, baixa latência, desempenho e flexibilidade de esquema, bem como garantias SQL e full-ACID, sem comprometer nenhuma de suas necessidades. Você paga o custo das transações somente quando necessário e, caso contrário, libera o sistema para que ele funcione em escala.

Couchbase 7.0 é um banco de dados em que você pode realizar operações de valor-chave, consultas SQL, transações ACID completas, pesquisas tokenizadas, streaming de eventos ou consultas analíticas ad-hoc - na nuvem ou na borda. O poder de trazer todos esses mecanismos para os JSONs que você escreve uma vez no banco de dados permite que seus desenvolvedores criem uma nova classe de aplicativos que ainda não foram imaginados.

Estou animado com o que a versão 7.0 do Couchbase oferece, mas fico ainda mais animado quando ouço falar de um aplicativo que você criou e I perguntam incrédulos: "Espere, você construiu isso no Couchbase?!".

Estou ansioso por isso,

Ravi