Os casos de uso estão impulsionando a divergência, e a convergência, das soluções NoSQL

Esta manhã, Matt Aslett, do The 451, publicou um artigo no blog sobre O começo do fim do NoSQL no qual ele destacou a inutilidade do nome da categoria NoSQL. Bom post, como de costume. Mas isso não é novidade. As pessoas vêm reclamando do termo desde o dia em que foi cunhado.

Concordo plenamente com o Matt que um foco em casos de uso (“qual problema você está tentando resolver?”) será muito mais produtivo do que focar em rótulos. Mas não concordo com o Matt quando ele parece dar a entender que seria muito mais útil categorizar em termos do modelo de dados subjacente (chave-valor, documento, orientado a colunas, grafo, etc.). Estas categorias oferecem apenas uma melhoria marginal se o foco for avaliar a adequação ao propósito de uma tarefa específica.

O Mongo é um banco de dados de documentos. O Couch também. No entanto, essas duas soluções estão indo em direções drasticamente diferentes sob a perspectiva de caso de uso.

Mongo é um banco de dados de documentos. Cassandra é um banco de dados orientado a colunas. Membase e o Riak são bancos de dados chave-valor. Mas essas soluções estão em rota de colisão direta do ponto de vista de casos de uso. Elas estão sendo avaliadas de forma intercambiável pelos clientes hoje e cada uma está vencendo ou perdendo, frequentemente com base em recursos que não têm nada a ver com o modelo de dados subjacente.

Sim, NoSQL é um nome de categoria inútil.

Há pelo menos duas boas razões pelas quais o apelido NoSQL é uma droga:

1. Alguns sistemas “NoSQL” na verdade fornecem dialetos de SQL como a linguagem de consulta para acessar dados dentro do banco de dados. O Google App Engine possui o linguagem GQL. A missão tem Toad for Cloud Databases que busca fornecer uma interface SQL para o HBase, Azure Tables, SimpleDB da Amazon e outros bancos de dados “NoSQL”. Colmeia traz um dialecto de SQL para o Hadoop, facilitando o ETL.
2. Como Matt aponta, há muitas classes diferentes de tecnologia agrupadas sob o rótulo NoSQL hoje. Sem dúvida sobre isso. Mas eu proponho que simplesmente falar em termos de um aspecto de uma pilha de tecnologia complexa nos aproxima apenas marginalmente de resolver o problema real. Os seres humanos são programados para desejar categorias bonitas e organizadas nas quais agrupar conceitos e coisas. Mas eu sugiro que NoSQL como um rótulo para o Mongo é apenas ligeramente menos útil do que dizer que o Mongo é um banco de dados de documentos, se o que você está tentando fazer é descobrir para que ele serve para.

Categorizar por modelo de dados também é praticamente inútil.

Então, qual seria um conjunto bom, limpo e representativo de categorias para todas essas soluções emergentes? Um que realmente permitisse a um observador determinar se a categoria da solução é ou não apropriada para um determinado caso de uso? Eu não tenho a resposta e não tenho certeza se existe uma boa resposta. Talvez os próprios casos de uso forneçam a categorização correta. De qualquer forma, estou ansioso para ler o relatório da 451 que o Matt indica que ajudará a estruturar o pensamento em torno dessas “alternativas de banco de dados”.”

Em última análise, categorizar essas soluções exigirá olhar além do modelo de dados subjacente isoladamente (chave-valor, documento, orientado a colunas, grafo, etc.). Em vez disso, esses sistemas devem ser comparados usando um conjunto maior, e esperamos que gerenciável, de atributos: você deve declarar um esquema antes de inserir dados? Você pode alterar o esquema em tempo de execução, caso seja necessário? Quão difícil é fazer isso? O banco de dados pode se expandir transparentemente (para uma aplicação) entre máquinas ou é uma solução focada em um único servidor? Você precisa desativar o banco de dados para adicionar ou remover capacidade? Você pode consultar o banco de dados usando uma linguagem de consulta ou precisa escrever código? O sistema mantém índices para acelerar as consultas? Como o banco de dados se sai em operações aleatórias e sequenciais? Como ele se sai em leituras versus gravações? Os dados são gravados em mídia durável imediatamente ou eventualmente, e qual é a minha exposição à perda de dados em caso de falha de nó? E quanto à falha de datacenter? Posso alterar essa exposição por meio de operações síncronas? O que isso fará com o desempenho? O banco de dados pode funcionar além dos limites do datacenter? Eu sempre poderei ler minhas próprias gravações ou há períodos de inconsistência de dados entre leitores?

Essas são certamente perguntas muito mais relevantes a serem feitas ao tentar determinar a adequação ao propósito para qualquer caso de uso específico. Novamente, há um coeficiente de correlação baixo ao comparar as respostas a estas perguntas com as categorias restritas em que esses sistemas estão sendo enquadrados; e pouco importa se você os encaixa todos em uma grande categoria “NoSQL”, ou se os divide em subcategorias baseadas em uma abordagem orientada a modelos de dados de eixo único (chave-valor, documento, orientado a colunas, grafo, etc.).

O NoSQL é apenas uma repetição do fiasco do OODBMS do final dos anos 90?

Por que há tanto barulho em torno do NoSQL, afinal? Isso é apenas uma repetição do *hype* do banco de dados orientado a objetos que todos nós vivemos no final dos anos 1990? Nesse fiasco, fornecedores de OODBMS, especialistas e investidores descartaram a tecnologia de banco de dados relacional como uma “correspondência de impedância” ruim para modelos de desenvolvimento de aplicativos orientados a objetos cada vez mais dominantes. Havia a alegação de que era mais “natural” para os desenvolvedores armazenarem dados no banco de dados em sua forma de objeto nativa, com argumentos de que seria mais eficiente também.

Mas, na realidade, havia pouca dor real sendo abordada. De fato, a mudança de uma tecnologia conhecida e funcional para uma solução não testada que prometia uma abordagem mais “elegante” e teoricamente correta na verdade só tinha uma coisa garantida: disrupção. Camadas de mapeamento objeto-relacional (ORM) projetadas para unir a “incompatibilidade” entre os modelos de dados de objetos e relacionais não são perfeitas; mas são melhores do que virar seu mundo de cabeça para baixo se você não precisar. As dezenas de bilhões de dólares em receita previstas por analistas para o mercado de OODBMS nunca chegaram perto de se concretizar.

Então, há um problema real agora? Um caso de uso real, ou casos de uso, para os quais as tecnologias de banco de dados existentes são verdadeiramente insuficientes? Onde a disrupção de uma mudança tecnológica terá impacto econômico substancial? A resposta é um categórico sim.

Os casos de uso estão impulsionando a divergência, e a convergência, das soluções NoSQL.

O sofá reivindicou a caso de uso de sincronização de dados móveis. Em um mundo da computação cada vez mais dominado por dispositivos móveis, a sincronização de dados entre a nuvem e os dispositivos móveis (para disponibilidade de dados mesmo quando desconectados da rede) é um problema que muitas aplicações precisam resolver. Há muitas coisas a considerar – conectividade intermitente, plataformas amplamente divergentes nas quais esses bancos de dados sincronizados devem ser executados e, talvez, a expectativa de que o conjunto de dados que está sendo movido e sincronizado normalmente precise caber em um único aparelho ou dispositivo. O Couch está focando nesses requisitos e fazendo suposições simplificadoras apropriadas, permitindo que o Couch atenda ao caso de uso melhor do que qualquer outro. O Couch é um banco de dados de documentos. O Mongo também. O Mongo é uma solução ruim para este caso de uso. Ele não foi projetado para manter sistemas conectados transitoriamente em sincronia e, apesar de o Mongo ter sido inicialmente projetado como um banco de dados de nó único, o trabalho de sharding e replicação feito no último ano indica claramente que o Mongo está indo em uma direção diferente. Neste caso, fica claro que divergência de soluções; mesmo dentro do segmento mais restrito de “bancos de dados de documentos” do mercado “NoSQL”.

Por outro lado, há a categoria cruzada convergência ocorrendo entre outras soluções NoSQL que buscam atender a outro caso de uso extremamente grande e generalizado: armazenar dados por trás de aplicações web interativas. Na Membase, conversamos com muitos usuários potenciais lidando com esse problema todas as semanas; e somos consistentemente avaliados em relação ao Cassandra (coluna), Mongo (documento) e Riak (também chave-valor).

As aplicações web que permitem às organizações interagir diretamente com os consumidores são cada vez mais a forma mais comum de novo sistema de software interativo sendo construído. Esses sistemas são caracterizados por padrões de uso simultâneo aleatório por grandes populações de usuários (grande público) e por sua propensão a acumular grandes conjuntos de dados (big data). Há também um impulso em direção ao modelo de computação em nuvem, particularmente para esta classe de aplicação, em que a “expansão horizontal” (adição de mais instâncias de máquinas em nuvem, máquinas virtuais ou servidores comuns) é preferida em relação à execução de cargas de trabalho em grandes máquinas dedicadas e de grande porte (“big iron”). Essas realidades levaram à necessidade generalizada de uma nova classe de sistema de gerenciamento de banco de dados que seja projetada, desde o início, para permitir escalabilidade horizontal e apoiar de forma custo-eficiente altos níveis de concorrência em relação a conjuntos de dados em rápido crescimento. Talvez possamos chamar isso de banco de dados em nuvem, o caso de uso de banco de dados elástico, banco de dados com escala horizontal (scale-out) ou banco de dados com auto-sharding (: P).

Então, o que um banco de dados precisa fornecer para resolver esse problema? Eu diria que ele precisa ser simples, rápido, elástico e seguro. Se você considerar o Membase, o Mongo, o Cassandra e o Riak, cada um dos quais visa explicitamente resolver esse problema generalizado de “banco de dados em nuvem”, as pontuações em cada um desses pontos variam.

Vamos pegar a primeira característica. Para ter sucesso, um banco de dados em nuvem de propósito geral deve ser simples de obter, de desenvolver e de operar em produção.

• O Membase é extremamente fácil de obter, instalar e começar a usar. Portanto, o Mongo é mais fácil que o Membase em alguns casos, e mais difícil em outros. O Cassandra é desafiador em praticamente todas as situações.
• Mongo é fácil de desenvolver em cima – fornecendo consultas ricas, gerenciamento de índices e a capacidade de operar em uma variedade de tipos de dados interessantes dentro do próprio banco de dados. O Membase fornece aos desenvolvedores uma API de chave-valor compatível com Memcached que, embora extremamente fácil de usar, impõe mais ônus ao desenvolvedor do aplicativo para muitas operações comuns de banco de dados do que o Mongo. O Cassandra apresenta um modelo de desenvolvimento mais complicado, mas permite consultas ricas. As consultas do Riak dependem exclusivamente de map-reduce.
• O Membase é fácil de gerenciar em produção, fornecendo um rico conjunto de ferramentas de monitoramento e gerenciamento que oferecem profunda visibilidade sobre a operação de um cluster de servidores pequeno ou grande, aumentando o tempo de atividade do sistema. O Mongo oferece muito menos visibilidade sobre a operação de um cluster, e essa deficiência foi a apontada principalmente pelo Mongo após a interrupção do FourSquare.

Uma comparação semelhante pode ser feita para cada uma das características restantes: rápido, elástico e seguro. Cada solução é forte em certas dessas áreas e relativamente fraca em outras.

Mas o ponto mais importante é que cada uma dessas soluções está se movimentando para suprir suas respectivas deficiências para melhor atender às necessidades dos clientes. Há uma convergência impulsionada pelo caso de uso. Nenhum projeto está focado simplesmente em ser um ótimo sistema de gerenciamento de banco de dados chave-valor, de documentos ou orientado a colunas. Cada um está focado em resolver um problema do mundo real – fornecer um local econômico para armazenar dados por trás de aplicações web interativas, conforme caracterizado anteriormente. Para esse fim, o Membase está adicionando recursos de consulta e indexação. O Mongo recentemente retroajustou o suporte a sharding e replicação à sua solução inicial de servidor único e está reprojetando seu mecanismo de armazenamento para aumentar a segurança dos dados. O Redis, outra solução “NoSQL”, está adicionando recursos de gerenciamento de cluster para se tornar verdadeiramente “elástico”. Há uma convergência clara entre as soluções direcionadas a este caso de uso. Cada um desses projetos identifica o direcionamento de anúncios e ofertas; jogos sociais; gerenciamento de estado de sessão de aplicativos web; e processamento de eventos em tempo real como casos de uso para os quais seus sistemas se destinam. Todos esses são casos de uso de aplicativos web interativos.

Não relacional é o fio tecnológico real e consistente em bancos de dados em nuvem

Há uma coisa que pode ser dita consistentemente sobre essas soluções de banco de dados em nuvem, de uma perspectiva técnica. Elas visam escalar horizontalmente, e isso é muito difícil (impossível) de ser feito de maneira econômica, com desempenho aceitável, empregando o modelo de dados relacional. Portanto, cada um desses sistemas de banco de dados “NoSQL” são sistemas “não relacionais”. Isso é, em última análise, o que se pretendia com “NoSQL”.”

Na verdade, cada um desses sistemas é, em sua essência, um armazenamento de chave-valor. Elas variam nas técnicas usadas para examinar os valores ou agrupá-los para operá-los (chave-valor enxerga o valor como um bloco opaco, documento enxerga o valor como uma coleção formatada de tipos de dados de atributos, o armazenamento orientado a colunas agrupa pares individuais de CV usando estruturas de dados separadas em “colunas”). Mas, em cada caso, em vez de desagregar um registro de dados (tupla) em entradas armazenadas em um conjunto normalizado de tabelas com referências cruzadas, como no modelo relacional, esses bancos de dados em nuvem armazenam os campos de dados de um “registro” específico em um único local. Isso torna muito fácil distribuir registros automaticamente (“fragmentar o banco de dados” ou fazer *shard*) por muitos nós em um cluster de banco de dados. Há prós e contras nessa abordagem.

No lado negativo, a desnormalização leva a aumentos no tamanho total do conjunto de dados (já que alguns dados são inevitavelmente armazenados várias vezes no banco de dados, onde haveria apenas referências em um banco de dados relacional normalizado) e aumenta a complexidade de realizar junções. No lado positivo, torna fácil espalhar dados por vários servidores baratos e alterar essa distribuição sob demanda sem interrupção da aplicação. Também elimina a exigência de pré-definir um esquema (ou alterar o esquema do banco de dados) antes de inserir dados. Na dúvida, armazene-os. Você pode inferir um esquema mais tarde. Isso torna muito mais fácil coletar informações que anteriormente poderiam ter ficado sem coleta. Em última análise, este é talvez o ponto onde a tecnologia de banco de dados NoSQL criará mais valor.

Então, vamos encontrar um nome melhor.

Estamos bem prontos para abandonar o rótulo NoSQL. Se as pessoas conseguirem se unir em torno de uma taxonomia mais centrada em casos de uso, acredito que isso seria uma vitória para os usuários que lutam para entender para que esses sistemas servem.

Banco de dados em nuvem é um nome que vai direto ao cerne do problema que o Membase está tentando resolver, por todas as razões articuladas acima. Mas pode ser um pouco moderno demais ou amorfo. Adoraria saber o que as pessoas acham.