Esta manhã, Matt Aslett, do The 451, publicou um blog sobre O começo do fim do NoSQL no qual ele destacou a inutilidade do nome da categoria NoSQL. Boa postagem, como sempre. Mas essa não é uma notícia nova. As pessoas têm se queixado do termo desde o dia em que ele foi criado.
Concordo plenamente com Matt que o foco em casos de uso ("que problema você está tentando resolver?") será muito mais produtivo do que o foco em rótulos. Mas discordo de Matt quando ele parece sugerir que pode ser mais útil categorizar em termos de modelo de dados subjacente (valor-chave, documento, orientado por coluna, gráfico etc.). Essas categorias oferecem apenas uma melhoria marginal se o foco for avaliar a adequação do propósito para uma tarefa específica.
O Mongo é um banco de dados de documentos. O Couch também é. Mas essas duas soluções estão indo em direções drasticamente diferentes do ponto de vista do caso de uso.
O Mongo é um banco de dados de documentos. O Cassandra é um banco de dados orientado por colunas. Membase e Riak são armazenamentos de valores-chave. Mas essas soluções estão em rota de colisão direta do ponto de vista dos casos de uso. Atualmente, elas estão sendo avaliadas de forma intercambiável pelos clientes e cada uma está ganhando 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 dois bons motivos pelos quais o apelido NoSQL é ruim:
- Alguns sistemas "NoSQL", na verdade, fornecem dialetos de SQL como a linguagem de consulta para acessar os dados no banco de dados. O Google App Engine tem o Linguagem GQL. A Quest tem Toad para bancos de dados em nuvem que busca fornecer uma interface SQL para o Hbase, Azure Tables, SimpleDB da Amazon e outros bancos de dados "NoSQL". Colmeia traz um dialeto de SQL para o Hadoop, facilitando a ETL.
- Como Matt aponta, há muitas classes diferentes de tecnologia agrupadas sob a bandeira NoSQL hoje. Não há dúvida quanto a isso. Mas proponho que simplesmente falar em termos de um aspecto de uma pilha de tecnologia complexa nos aproxima apenas marginalmente da solução do problema real. Os seres humanos são programados para desejar categorias bem organizadas para agrupar conceitos e coisas. Mas sugiro que o NoSQL como rótulo para o Mongo é apenas um pouco menos útil do que dizer que o Mongo é um banco de dados de documentos, Se o que você está tentando fazer é descobrir o que é bom para.
A categorização por modelo de dados também é bastante inútil.
Então, qual seria um conjunto de categorias agradável, limpo e representativo para todas essas soluções emergentes? Um conjunto que realmente permitisse a um observador determinar se a categoria da solução é apropriada ou não para um determinado caso de uso? 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, segundo Matt, ajudará a estruturar o pensamento sobre essas "alternativas de banco de dados".
Por fim, a categorização dessas soluções exigirá que se olhe além do modelo de dados subjacente (valor-chave, documento, orientado a colunas, gráfico etc.). Em vez disso, esses sistemas devem ser comparados por meio de um conjunto maior de atributos, que se espera sejam gerenciáveis: Você precisa declarar um esquema antes de inserir dados? É possível alterar o esquema em tempo real se for necessário? Qual é a dificuldade de fazer isso? O banco de dados pode se espalhar de forma transparente (para um aplicativo) entre máquinas ou é uma solução focada em um único servidor? É necessário desativar o banco de dados para adicionar ou remover capacidade? É possível consultar o banco de dados usando uma linguagem de consulta ou é necessário escrever código? O sistema mantém índices para acelerar as consultas? Qual é o desempenho do banco de dados em operações aleatórias e sequenciais? Qual é o desempenho 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 do nó? E em caso de falha do data center? 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 data center? Eu sempre lerei minhas gravações ou haverá períodos de inconsistência de dados entre os leitores?
Essas são, sem dúvida, perguntas muito mais relevantes a serem feitas quando se tenta determinar a adequação à finalidade de um determinado caso de uso. Mais uma vez, há um baixo coeficiente de correlação ao comparar as respostas a essas perguntas com as categorias restritas nas quais esses sistemas estão sendo encaixadosE pouco importa se você os coloca em uma grande categoria "NoSQL" ou se os divide em subcategorias com base em uma abordagem orientada por modelo de dados de eixo único (valor-chave, documento, orientado por coluna, gráfico etc.).
O NoSQL é apenas uma repetição do fiasco do OODBMS do final dos anos 90?
Afinal, por que há tanto barulho em torno do NoSQL? Será que isso é apenas uma repetição do hype dos bancos de dados orientados a objetos que todos nós vivemos no final dos anos 90? Naquele fiasco, os fornecedores, especialistas e investidores de OODBMS jogaram a tecnologia de banco de dados relacional no lixo por considerá-la uma "combinação de impedância" ruim para os modelos de desenvolvimento de aplicativos orientados a objetos cada vez mais dominantes. Os desenvolvedores alegaram que era mais "natural" armazenar dados no banco de dados em sua forma de objeto nativo, com argumentos de que isso também seria mais eficiente.
Mas, na realidade, havia pouca dor real sendo resolvida. De fato, a mudança de uma tecnologia conhecida e funcional para uma solução não comprovada, que prometia uma abordagem mais "elegante" e teoricamente correta, na verdade só garantia uma coisa: interrupção. As camadas de mapeamento objeto-relacional (ORM) projetadas para suprir a "incompatibilidade" entre os modelos de dados objeto e relacional não são perfeitas, mas são melhores do que virar o mundo de cabeça para baixo, se não for necessário. As dezenas de bilhões de dólares em receita previstas pelos analistas para o mercado de OODBMS nunca chegaram nem perto de se concretizar.
Então, existe 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 realmente insuficientes? Em que a interrupção de uma mudança tecnológica terá um impacto econômico significativo? A resposta é um sonoro sim.
Os casos de uso estão impulsionando a divergência e a convergência das soluções NoSQL.
O Couch se tornou uma referência no Caso de uso de sincronização de dados móveis. Em um mundo de 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 muitos aplicativos precisam resolver. Há muitos aspectos a serem considerados - 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 uma única caixa ou dispositivo. O Couch está se concentrando nesses requisitos e fazendo suposições simplificadoras apropriadas, o que permite que o Couch atenda ao caso de uso melhor do que qualquer outro. O Couch é um banco de dados de documentos. Assim como o Mongo. O Mongo é uma solução ruim para esse caso de uso. Ele não foi projetado para manter sistemas conectados transitoriamente em sincronia e, apesar de o Mongo ter sido projetado inicialmente como um banco de dados de nó único, o trabalho de sharding e replicação realizado no último ano indica claramente que o Mongo está se movendo em uma direção diferente. Nesse caso, há claramente divergência de soluções, mesmo dentro da fatia mais restrita de "banco de dados de documentos" do mercado "NoSQL".
Por outro lado, há uma categoria cruzada convergência O Membase está entre outras soluções NoSQL que buscam atender a outro caso de uso extremamente grande e generalizado: armazenar dados por trás de aplicativos interativos da Web. Na Membase, conversamos com muitos usuários em potencial que enfrentam esse problema todas as semanas; e somos constantemente avaliados em relação ao Cassandra (coluna), Mongo (documento) e Riak (também valor-chave).
Os aplicativos da Web que permitem que as organizações interajam diretamente com os consumidores são, cada vez mais, a forma mais comum de novo sistema de software interativo que está sendo criado. Esses sistemas são caracterizados por padrões aleatórios de uso simultâneo 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, especialmente para essa classe de aplicativos, em que o "escalonamento" (adição de mais instâncias de máquinas em nuvem, máquinas virtuais ou servidores de commodities) é preferível à execução de cargas de trabalho em máquinas grandes, dedicadas e "big iron". Essas realidades levaram à necessidade generalizada de uma nova classe de sistema de gerenciamento de banco de dados projetado, desde o início, para permitir escalonamento horizontal e para oferecer suporte econômico a altas medidas de simultaneidade em relação a conjuntos de dados em rápido crescimento. Talvez possamos chamar isso de banco de dados em nuvemO caso de uso do banco de dados elástico, do banco de dados de expansão horizontal ou do banco de dados de fragmentação automática (: P).
Então, o que um banco de dados precisa oferecer 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 deles com o objetivo explícito de resolver esse problema generalizado de "banco de dados em nuvem", as pontuações em cada um desses pontos variam.
Vamos nos concentrar na primeira característica. Para ter sucesso, um banco de dados em nuvem de uso geral deve ser simples de obter, desenvolver e operar na produção.
- O Membase é extremamente fácil de obter, instalar e começar a usar. O mesmo acontece com o Mongo - mais fácil do que o Membase em alguns casos, mais difícil em outros. O Cassandra é desafiador em praticamente todas as situações.
- Mongo é fácil de desenvolver contra - 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 valor-chave compatível com o Memcached que, embora seja extremamente fácil de usar, sobrecarrega o desenvolvedor do aplicativo em muitas operações comuns de banco de dados, em comparação com o Mongo. O Cassandra apresenta um modelo de desenvolvimento mais complicado, mas permite consultas ricas. As consultas do Riak dependem exclusivamente do map-reduce.
- Membase é fácil de gerenciar na produçãoO Mongo é um software de monitoramento e gerenciamento que oferece um rico conjunto de ferramentas de monitoramento e gerenciamento que fornecem informações detalhadas sobre a operação de um cluster pequeno ou grande de servidores, aumentando o tempo de atividade do sistema. O Mongo fornece muito menos informações sobre a operação de um cluster, e essa deficiência foi a principal apontada pelo Mongo após a interrupção do FourSquare.
Uma comparação semelhante pode ser feita para cada uma das características restantes: rápida, elástica e segura. Cada solução é forte em algumas dessas áreas e relativamente fraca em outras.
Mas o ponto mais importante é que cada uma dessas soluções está se movendo para suprir suas deficiências relativas para atender melhor às necessidades dos clientes. Há uma convergência orientada pelo caso de uso. Nenhum projeto está focado em ser simplesmente um excelente sistema de gerenciamento de banco de dados orientado a chave-valor, documento ou coluna. Cada um deles está focado em resolver um problema do mundo real - fornecer um local econômico para armazenar dados por trás de aplicativos interativos da Web, conforme caracterizado anteriormente. Para esse fim, o Membase está adicionando recursos de consulta e indexação. O Mongo recentemente adaptou o suporte a sharding e réplica à sua solução inicial de servidor único e está redesenhando 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 clara convergência entre as soluções voltadas para esse caso de uso. Cada um desses projetos identifica a segmentação de anúncios e ofertas; jogos sociais; gerenciamento do estado da sessão de aplicativos da Web; e processamento de eventos em tempo real como casos de uso para os quais seu sistema se destina. Todos esses são casos de uso de aplicativos interativos da Web.
A tecnologia não relacional é o fio condutor real e consistente dos bancos de dados em nuvem
Há uma coisa que pode ser dita de forma consistente sobre essas soluções de banco de dados em nuvem, de uma perspectiva técnica. Elas têm o objetivo de escalonar horizontalmente, o que é muito difícil (impossível) de fazer de forma 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". Em última análise, esse é o objetivo do "NoSQL".
Na verdade, cada um desses sistemas é, em sua essência, um armazenamento de valores-chave. Eles variam nas técnicas usadas para examinar os valores ou para agrupar os valores a fim de operá-los (o valor-chave vê o valor como um blob opaco, o documento vê o valor como uma coleção de tipo de dados de atributo formatado, o armazenamento orientado por coluna agrupa pares KV individuais usando uma estrutura de dados separada 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 determinado "registro" em um único local. Isso facilita muito a distribuição automática de registros ("fragmentar o banco de dados") em vários nós de um cluster de banco de dados. Há prós e contras nessa abordagem.
No lado negativo, a desnormalização leva a um aumento no tamanho total do conjunto de dados (já que alguns dados são inevitavelmente armazenados várias vezes no banco de dados, onde, em vez disso, haveria apenas referências em um banco de dados relacional normalizado) e aumenta a complexidade das junções. Como vantagem, isso facilita a distribuição de dados em muitos servidores baratos e a alteração dessa distribuição sob demanda, sem interrupção do aplicativo. Também elimina a necessidade de pré-definir um esquema (ou alterar o esquema do banco de dados) antes de inserir dados. Em caso de dúvida, armazene-os. Você pode inferir um esquema mais tarde. Isso facilita muito a coleta de informações que antes poderiam não ter sido coletadas. Em última análise, talvez esse seja o lugar em que a tecnologia de banco de dados NoSQL criará mais valor.
Então, vamos encontrar um nome melhor.
Estamos prontos para abandonar o rótulo NoSQL. Se as pessoas puderem se unir em torno de uma taxonomia que seja mais centrada em casos de uso, acredito que isso seria uma vitória para os usuários que lutam para descobrir para que esses sistemas são bons.
Banco de dados em nuvem é um nome que chega ao cerne do problema que o Membase está tentando resolver, por todos os motivos expostos acima. Mas talvez seja um pouco moderno ou amorfo demais. Gostaria muito de saber a opinião das pessoas.
