Um guia de NoSQL para desenvolvedores

Se você acompanha as tendências em desenvolvimento de back-end e Big Data, provavelmente já percebeu o burburinho em torno dos bancos de dados NoSQL nos últimos anos. Algumas pessoas são inspiradas por esta abordagem ao banco de dados, enquanto outras pensam que há algum tipo de truque escondido nela: os modelos de dados neles não são os mesmos dos bancos de dados relacionais usuais, as interfaces de programação de aplicativos são incomuns e o aplicações são muitas vezes incompreensíveis. Neste artigo vou contar por que eles foram criados em primeiro lugar, esses bancos de dados NoSQL, quais problemas eles resolvem e por que tantos bancos de dados diferentes são repentinamente necessários. Se você é novo no NoSQL, pode estar particularmente interessado na última parte do artigo, que lista os tipos de banco de dados NoSQL que acho que valem a pena explorar primeiro para obter uma compreensão completa do campo.

Por que de repente precisamos de um novo banco de dados?

Você pode ficar confuso ao perguntar: o que há de errado com os bancos de dados relacionais? A questão é que eles funcionaram muito bem durante muitos anos, mas agora há um problema que eles não conseguem mais resolver. Segundo algumas previsões, em 2018 a humanidade irá gerar 50.000 gigabytes de dados por segundo. Esta é uma quantidade colossal de dados! Seu armazenamento e manuseio representam um sério desafio de engenharia. O que é ainda pior é que esse volume está em constante crescimento. Acontece que os bancos de dados relacionais são pouco adequados para trabalhar com volumes realmente grandes de dados. Eles são projetados para rodar em uma única máquina e, se você quiser atender a mais solicitações, a única opção é comprar um computador com mais RAM e um processador mais potente. Infelizmente, o número de consultas que uma máquina pode tratar é limitado e, para trabalho distribuído em diversas máquinas, precisamos de uma tecnologia de banco de dados diferente. É claro que alguns leitores irão rir neste momento e dizer que existem dois métodos amplamente utilizados para usar múltiplas máquinas no caso de um banco de dados relacional: replicação e fragmentação. Isso é verdade, mas estes métodos não são suficientes para lidar com as nossas tarefas. A replicação de leitura é uma técnica na qual cada atualização do banco de dados é propagada para outras máquinas que só podem lidar com solicitações de leitura. Nesse caso, todas as alterações são realizadas por um servidor, denominado nó mestre, enquanto outros servidores, chamados de réplicas de leitura, mantêm apenas cópias dos dados. O usuário pode ler em qualquer uma das máquinas, mas alterar os dados apenas através do nó mestre. Este é um método conveniente e muito popular, mas apenas permite processar mais solicitações de leitura e não resolve de forma alguma o problema de processamento dos volumes de dados necessários. Sharding é outra abordagem popular que usa múltiplas instâncias de um banco de dados relacional. Cada um deles lida com operações de gravação e leitura para uma parte dos dados. Se um banco de dados armazena informações sobre clientes, por exemplo, usando sharding, uma máquina pode lidar com todas as solicitações de clientes cujos nomes começam com A, outra máquina pode armazenar todos os dados de clientes cujos nomes começam com B e assim por diante. Embora a fragmentação permita registrar mais dados, gerenciar esse banco de dados é um verdadeiro pesadelo: você precisa alinhar os dados entre as máquinas e dimensionar o cluster em ambas as direções, conforme necessário. Embora pareça simples na teoria, acertar é bastante desafiador.

Os bancos de dados relacionais podem ser melhorados?

Acho que você já passou a acreditar que os bancos de dados relacionais não são os mais adequados para o volume de dados gerados no mundo moderno. Embora você ainda possa estar se perguntando por que ninguém ainda criou um banco de dados relacional “melhor” que possa ser executado com eficiência em várias máquinas. Pode parecer que esta tecnologia simplesmente ainda não foi desenvolvida e bancos de dados relacionais distribuídos aparecerão muito em breve. Infelizmente, isso não acontecerá. Isto é matematicamente impossível e nada pode ser feito a respeito. Para entender por que isso acontece, você precisa examinar o chamado teorema CAP (também conhecido como teorema de Brewer). Foi comprovado em 1999 e afirma que um banco de dados distribuído rodando em múltiplas máquinas pode ter as três propriedades a seguir: Consistência - qualquer operação de leitura retorna os resultados da última operação de gravação correspondente. Se o sistema for consistente, após gravar novos dados, é impossível ler os dados antigos já sobrescritos. Disponibilidade ( A disponibilidade) - um sistema distribuído pode atender uma solicitação recebida a qualquer momento e retornar uma resposta sem erros. Tolerância de partição – o banco de dados continua respondendo a solicitações de leitura e gravação mesmo quando alguns de seus servidores estão temporariamente impossibilitados de se comunicarem entre si. Essa falha temporária é chamada de falha de conectividade de rede e pode ser causada por diversos fatores, desde problemas físicos de rede devido a um servidor lento até danos físicos ao equipamento de rede. Todas essas propriedades são certamente úteis e gostaríamos muito de um banco de dados para combinar todas elas. Nenhum desenvolvedor sensato gostaria de desistir, digamos, da acessibilidade sem receber nada em troca. Infelizmente, o teorema CAP também afirma que é impossível que todas as três propriedades sejam válidas simultaneamente. Perceber isso pode não ser fácil, mas é possível. Primeiro, se precisarmos de um banco de dados distribuído, ele deverá ser “tolerante à desconexão”. Isso nem é discutido. As desconexões acontecem o tempo todo e nosso banco de dados deve funcionar apesar disso. Agora vamos entender por que não conseguimos consistência e disponibilidade. Imagine que temos um banco de dados simples rodando em duas máquinas: A e B. Qualquer usuário pode gravar em qualquer uma das máquinas, após o que os dados são copiados para a outra. Agora imagine que essas máquinas estão temporariamente impossibilitadas de se comunicar entre si e a máquina B não consegue enviar ou receber dados da máquina A. Se durante esse período a máquina B receber uma solicitação de leitura de um cliente, ela terá duas opções:

1. Recupere seus dados locais, mesmo que não sejam os mais recentes. Neste caso, dá-se preferência à disponibilidade (para retornar pelo menos alguns dados, mesmo os desatualizados).
2. Erro de retorno. Nesse caso, prefere-se a consistência: o cliente não receberá dados desatualizados, mas não receberá nenhum dado.

Os bancos de dados relacionais se esforçam para incorporar as propriedades de “consistência” e “disponibilidade” simultaneamente e, portanto, não podem operar em um ambiente distribuído. Tentar implementar todas as capacidades de um banco de dados relacional em um sistema distribuído será irrealista ou simplesmente inviável . Por outro lado, os bancos de dados NoSQL colocam ênfase principal na escalabilidade e no desempenho. Eles geralmente não possuem recursos “básicos”, como conexões e transações, e o modelo de dados acaba sendo completamente diferente, talvez até limitador de alguma forma. Tudo isto permite armazenar maiores volumes de dados e processar mais consultas do que nunca.

Como os bancos de dados NoSQL equilibram consistência e disponibilidade?

Pode parecer que se você escolher um banco de dados NoSQL, sempre receberá alguns dados desatualizados ou um erro em caso de falha. Na prática, a disponibilidade e a consistência não são de forma alguma as únicas opções disponíveis. Há uma ampla gama de opções disponíveis para você escolher. Os bancos de dados relacionais não possuem essas opções, mas o NoSQL permite controlar a execução de consultas de maneira semelhante. De uma forma ou de outra, eles permitem definir dois parâmetros ao realizar operações de gravação ou leitura em um banco de dados NoSQL: W - quantas máquinas no cluster devem confirmar o salvamento dos dados ao realizar uma operação de gravação . Quanto maior o número de máquinas onde você grava seus dados, mais fácil será ler os dados mais recentes na próxima operação de leitura, mas também mais tempo levará. R – de quantas máquinas você gostaria de ler dados . Em um sistema distribuído, a distribuição de dados para todas as máquinas em um cluster pode levar algum tempo, portanto, alguns servidores terão os dados mais recentes, enquanto outros ficarão atrasados. Quanto maior o número de máquinas nas quais os dados são lidos, maiores serão as chances de leitura dos dados atuais. Vejamos um exemplo prático. Se você tiver cinco computadores em seu cluster e decidir gravar dados em apenas um e depois ler os dados de um computador selecionado aleatoriamente, há 80% de chance de você ler dados obsoletos. Por outro lado, isso utilizará um mínimo de recursos. Portanto, se os dados legados estão bem para você, não é uma opção tão ruim. Neste caso, os parâmetros W e R são iguais a 1. Por outro lado, se você gravar dados em todas as cinco máquinas em um banco de dados NoSQL, poderá ler dados de qualquer máquina e ter a garantia de obter dados sempre atualizados. Executar a mesma operação em um número maior de máquinas levará mais tempo, mas se dados atualizados forem importantes para você, você poderá escolher esta opção. Neste caso, W = R = 5. Qual é o número mínimo de leituras e gravações necessárias para a consistência do banco de dados? Aqui está uma fórmula simples: R + W ≥ N + 1 , onde N é o número de máquinas no cluster. Isto significa que com cinco servidores, você pode escolher entre R = 2 e W = 4, ou R = 3 e W = 3, ou R = 4 e W = 2. Neste caso, não importa para quais máquinas os dados serão transferidos. está escrito, a leitura sempre será feita em pelo menos uma máquina com dados atualizados. Outros bancos de dados, como o DynamoDB, possuem restrições diferentes e permitem apenas gravações consistentes. Cada dado é armazenado em três servidores e, quando qualquer dado é gravado, ele é gravado em duas das três máquinas. Mas ao ler os dados, você pode escolher uma das duas opções:

1. Leitura estritamente consistente, na qual os dados são lidos de duas máquinas em cada três e sempre retornam os últimos dados gravados.
2. Uma eventual leitura consistente, na qual uma máquina é selecionada aleatoriamente para ler os dados. No entanto, isso pode retornar temporariamente dados desatualizados.

Por que existem tantos bancos de dados NoSQL?

Se você acompanha as últimas notícias na área de desenvolvimento de software, provavelmente já ouviu falar de diversos bancos de dados NoSQL, como MongoDB, DynamoDB, Cassandra, Redis e muitos outros. Você deve estar se perguntando: por que precisamos de tantos bancos de dados NoSQL diferentes? A razão é simples: diferentes bancos de dados NoSQL são projetados para resolver problemas diferentes. É por isso que o número de bancos de dados concorrentes é tão grande. Os bancos de dados NoSQL se enquadram em quatro categorias principais:

Bancos de dados orientados a documentos

Esses bancos de dados oferecem a capacidade de armazenar documentos aninhados complexos, enquanto a maioria dos bancos de dados relacionais oferece suporte apenas a linhas unidimensionais. Este recurso pode ser útil em muitos casos, por exemplo, quando é necessário armazenar informações sobre um usuário com diversos endereços no sistema. Ao usar um banco de dados orientado a documentos, neste caso você pode simplesmente armazenar um objeto complexo contendo uma matriz de endereços, enquanto em um banco de dados relacional você teria que criar duas tabelas: uma para informações do usuário e outra para endereços. Os bancos de dados orientados a documentos preenchem a lacuna entre o modelo de objetos e o modelo de dados. Alguns bancos de dados relacionais, como o PostgreSQL, agora também suportam armazenamento orientado a documentos, mas a maioria dos bancos de dados relacionais ainda não possui esse recurso.

Bancos de dados de chave/valor

Os bancos de dados de chave/valor normalmente implementam o modelo NoSQL mais simples. Essencialmente, eles fornecem uma tabela hash distribuída , permitindo gravar dados em uma determinada chave e lê-los novamente usando-a. Os bancos de dados de chave/valor são altamente escalonáveis ​​e têm latência significativamente menor do que outros bancos de dados.

Bancos de dados gráficos

Muitas áreas temáticas, por exemplo, redes sociais ou informações sobre filmes e atores, podem ser representadas como gráficos. Embora o gráfico possa ser representado usando um banco de dados relacional, é difícil e inconveniente. Se você precisar de dados gráficos, é melhor usar um banco de dados gráfico especializado, que pode armazenar informações sobre o gráfico em um cluster distribuído e possibilitar a implementação eficiente de algoritmos em gráficos.

Bancos de dados colunares

A principal diferença entre bancos de dados colunares e outros tipos de bancos de dados é a forma como os dados são armazenados no disco. Os bancos de dados relacionais criam um arquivo para cada tabela e armazenam os valores de todas as linhas sequencialmente. Os bancos de dados colunares criam um arquivo para cada coluna das suas tabelas. Essa estrutura permite agregar dados e executar determinadas consultas com mais eficiência, mas você deve garantir que os dados atendam às limitações de tais bancos de dados.

Qual banco de dados você deve escolher?

Escolher um banco de dados costuma ser um problema frustrante e, com tantas opções disponíveis, pode parecer uma tarefa árdua. A boa notícia é que não há necessidade de escolher apenas um. Em vez de criar um único aplicativo monolítico que implemente todos os recursos e tenha acesso a todos os dados do sistema, você pode usar outro padrão moderno chamado microsserviços : dividir o aplicativo em um conjunto de serviços independentes. Cada serviço resolve seu próprio problema restrito e utiliza apenas seu próprio banco de dados, que é mais adequado para solucionar esse problema.

Como você vai aprender tudo isso?

Com tantos bancos de dados , aprender todos eles pode parecer uma tarefa impossível. Boas notícias: você não precisa fazer isso. Existem apenas alguns tipos básicos de bancos de dados NoSQL e, se você entender como eles funcionam, os outros serão muito mais fáceis de entender. Além disso, alguns bancos de dados NoSQL são usados ​​com muito mais frequência do que outros, por isso é melhor concentrar seus esforços nas soluções mais populares. Aqui está uma lista dos bancos de dados NoSQL mais comumente usados ​​que acho que você deveria dar uma olhada:

1. MongoDB . Provavelmente o banco de dados NoSQL mais popular do mercado. Se uma empresa não usa um banco de dados relacional como armazenamento de dados primário, provavelmente ela usa o MongoDB. Este é um armazenamento flexível de documentos com um bom conjunto de ferramentas. No início de sua carreira, o MongoDB tinha uma má reputação por perder dados em alguns casos , mas desde então sua estabilidade e confiabilidade melhoraram bastante. Dê uma olhada neste curso MongoDB se quiser saber mais.


2. DynamoDB . Se você usa Amazon Web Services (AWS), é melhor aprender mais sobre o DynamoDB. É um banco de dados extremamente confiável, escalonável e de baixa latência, com rico conjunto de recursos e integração com muitos outros serviços da AWS. A melhor parte é que você não precisa implantá-lo sozinho. Configurar um cluster DynamoDB escalável que possa lidar com milhares de consultas está a apenas alguns cliques de distância. Se isso lhe interessa, você pode dar uma olhada neste curso .


3. Neo4j . O banco de dados gráfico mais comum. Esta é uma solução escalável e estável, adequada para quem deseja usar um modelo de dados gráficos. Se você quiser saber mais, comece com este curso .


4. Redis . Enquanto os outros bancos de dados descritos aqui são usados ​​para armazenar dados principais do aplicativo, o Redis é usado principalmente para implementar caches e armazenar dados auxiliares. Em muitos casos, um dos bancos de dados mencionados acima é usado em conjunto com o Redis. Para saber mais, confira este curso.

Em 2018 com NoSQL

Os bancos de dados NoSQL são um campo vasto e em rápido crescimento. Eles permitem armazenar e processar quantidades de dados anteriormente inimagináveis, mas isso tem um custo. Esses bancos de dados não possuem muitos dos recursos com os quais você está familiarizado nos bancos de dados relacionais e pode ser difícil se preparar para usá-los. Mas depois de dominá-los, você poderá criar bancos de dados escalonáveis ​​e distribuídos que podem lidar com volumes surpreendentes de solicitações de leitura e gravação, o que pode ser extremamente importante à medida que volumes cada vez maiores de dados são gerados. Original: https://simpleprogrammer.com/guide-nosql-software-developers/