O NoSQL subiu nas paradas como a próxima grande novidade na arquitetura de sistema em 2011, mas o interesse geral nele se estabilizou recentemente. Você pode ter ouvido falar e ignorado, sabendo que sempre pode ter uma linha de comando SQL ao seu alcance. Mas o que é NoSQL, o que isso tem a ver com o desenvolvimento moderno e vale a pena implementar em seu projeto?

Vamos descobrir.

Os administradores de sistemas que gerenciam grandes projetos sabem algumas coisas sobre bancos de dados SQL tradicionais. Primeiro, eles são notoriamente difíceis de escalar, dificultando a disseminação de dados entre serviços ou regiões geográficas. Um pequeno erro em um único arquivo pode sobrecarregar um banco de dados inteiro. E embora as instruções SQL sejam divertidas, é fácil descartar todas as tabelas enquanto mexer com uma chave ou corromper um repositório inteiro com uma consulta malformada. 

O objetivo de um banco de dados NoSQL, por outro lado, é garantir a escalabilidade final, garantindo que os dados sejam armazenados em um formato que possa ser compartilhado - ou fragmentado - em vários servidores. Os bancos de dados NoSQL são escalados de maneira muito mais linear do que os bancos de dados relacionais, ou seja, aqueles que dependem de várias chaves compartilhadas entre tabelas. Os bancos de dados NoSQL vêm em vários sabores: 

Armazenamentos de documentos indexados como MongoDB

Bancos de dados gráficos como Neo4j

Lojas de colunas como Cassandra

Bancos de dados de séries temporais, que indexam dados por registros de tempo, como o InfluxDB.

Formas híbridas que usam múltiplos dos paradigmas anteriores

Alguns deles até armazenam em formato de tabela. O que há de comum entre todos eles, porém, é que, independentemente do formato em que armazenam os dados, esses bancos de dados não oferecem suporte a relações entre os dados.

NoSQL não é brincadeira

Compreender os bancos de dados NoSQL leva um minuto para ser compreendido. O SQL tradicional usa tabelas relacionadas conectadas por IDs. Uma única entidade de domínio pode ser fragmentada ou normalizada em várias tabelas, o que significa que a sobrecarga necessária para garantir que um registro seja preciso pode ser imensa. Em vez de, digamos, uma tabela para IDs de usuário e, em seguida, uma tabela para endereços, NoSQL permite criar um objeto de usuário generalizado que contém tudo o que é importante sobre esses usuários. A vantagem disso é que você pode replicar facilmente o banco de dados em vários dispositivos, garantindo a capacidade de escalar e replicar.

Além disso, um banco de dados NoSQL permite acesso rápido a muitos dados. Um SQL, ou banco de dados relacional, é excelente para processamento de dados - criando conexões granulares entre pedaços de dados. Um banco de dados NoSQL é ótimo para localizar um dado rapidamente e operar nele. Há pouca ou nenhuma procura; apenas fornece os dados do usuário.

Como funciona

Muitos tipos de bancos de dados NoSQL são projetados para pesquisas rápidas de dados. Em vez de escrever uma consulta complexa, muitos usam um único valor - uma chave, um carimbo de data / hora, um documento - e extraem os dados armazenados sob esse valor. Ou seja, se você espera saber os detalhes de uma conta de usuário, todos os dados do usuário podem ser recuperados lendo o registro desse usuário. As relações entre os diferentes registros não são importantes e os dados podem mudar - um registro pode conter vários endereços, enquanto outro não pode conter nenhum. 

Como empresas como o Google e a Amazon criaram esses bancos de dados para seus próprios grandes armazenamentos de dados, o objetivo era reduzir o tempo necessário para obter um dado. Na verdade, o NoSQL renuncia às expectativas tradicionais do banco de dados de atomicidade, consistência, isolamento e durabilidade - ACID - para uma interpretação muito mais livre do armazenamento de dados.

Usar um banco de dados NoSQL não significa que você não pode usar SQL; SQL é apenas a linguagem de consulta. Na verdade, NoSQL e SQL podem ser complementares. Alguns bancos de dados NoSQL usam SQL para pesquisar os dados. Aqueles que não podem ser analisados ​​usando um mecanismo de consulta SQL como o Presto ou enviados por meio de um pipeline de dados para data warehouses mais analisáveis. Para ser justo, um bom pipeline de dados requer processamento ETL sofisticado para colocar os dados finais em um estado utilizável. 

Como um banco de dados SQL usa um esquema ou estrutura, isso significa que as mudanças são difíceis. Digamos que você esteja executando um banco de dados de produção cheio de um milhão de registros. Adicionar um único campo é um pesadelo e pode destruir todo o banco de dados. Além disso, conectar esses milhões de registros por meio de junções é extremamente caro. Isso significa que você pode pesquisar facilmente um determinado dado e conectá-lo a outro quando estiver procurando alguns registros e algumas tabelas. Multiplique isso, entretanto, e você terá uma dor de cabeça.

Bancos de dados NoSQL como MongoDB apenas pegam dados e os armazenam. Quer adicionar um campo? Adicione-o ao próximo registro armazenado. Quer ignorar um campo? Só não leia. Você pode adicionar vários endereços a um registro de usuário, por exemplo, ou nenhum. Você pode adicionar um sobrenome ou evitar adicionar um sobrenome. E como você pode fragmentar os dados, pode enviar alguns dados a um servidor em uma jurisdição não confiável e outros dados em uma jurisdição confiável. O banco de dados considera cada pedaço como parte de um todo.

Consultar dados é um pouco mais difícil. Cassandra do Apache usa Cassandra Query Language ou CQL que, curiosamente, não permite junções. O MongoDB apenas envia objetos JSON em reação a solicitações. Precisa de todos os usuários em Ohio? O MongoDB envia uma grande quantidade de dados. Quer deletar todos os usuários da Espanha? O MongoDB executará a pesquisa e executará a ação.

Além disso, não há necessidade de executar ping em todos os servidores para obter alguns dados. O servidor mais próximo não compartilhará nada com outros servidores e, em vez disso, retornará o que possui. Em algum ponto, todos os dados são replicados, mas cada servidor funciona em um vácuo. Isso significa que as alterações nos registros em um servidor não afetarão uma consulta feita em outro servidor.

 Benefícios do NoSQL

Bancos de dados NoSQL - MongoDB sendo o mais popular - são ótimos para escalonamento. Como os bancos de dados usam fragmentação para particionar dados em várias máquinas, você pode garantir que os dados certos estejam no lugar certo na hora certa. Além disso, uma interrupção em uma máquina não derrubará toda a rede. Conforme os dados aumentam, o banco de dados pode simplesmente expandir para outro dispositivo conforme necessário e encolher se as coisas ficarem mais lentas. Você também pode, digamos, armazenar dados geoespecíficos em servidores geoespecíficos, garantindo que as chamadas de um determinado país sejam mais rápidas em dados relacionados especificamente a esse país.

Em seguida, os bancos de dados NoSQL oferecem alta disponibilidade. Como os dados são simplesmente um único arquivo, você pode copiar backups de outros servidores na rede. Se um servidor falhar, outro servidor pode assumir o fragmento desse servidor e incorporá-lo. Os dados são constantemente replicados e seguros.

Os problemas

Os bancos de dados NoSQL não oferecem muito em termos de gerenciamento de transações ou codificação real. Eles são ótimos para armazenar dados que não mudam muito ou mudam minuciosamente a cada transação. Os sistemas NoSQL têm sido assustadores para novos usuários. Embora as soluções hospedadas estejam disponíveis, executar sua própria instância simples não é tão fácil quanto, digamos, ativar um servidor MySQL. 

Por fim, como todo o banco de dados pode conter muitos dados duplicados, o banco de dados real é muito grande. Existem vários tipos de bancos de dados NoSQL, sendo a solução baseada em documentos a mais prevalente. No entanto, você também pode usar bancos de dados de valor-chave como Redis, bem como aqueles tabulares como Hbase e Acculuo.

Uma solução baseada em chave como o Redis é um pouco mais familiar para os administradores, e o Redis em particular tem desempenho porque armazena muitos de seus dados na memória. Bancos de dados tabulares como o Hbase oferecem um sistema ligeiramente diferente que enfoca, de acordo com a documentação, "tabelas muito grandes - bilhões de linhas X milhões de colunas - em cima de clusters de hardware de mercadoria".

Se o NoSQL oferece tanta liberdade e flexibilidade, por que não abandonar totalmente o SQL? A resposta simples: muitos aplicativos ainda exigem os tipos de restrições, consistência e salvaguardas que os bancos de dados SQL fornecem. Nesses casos, algumas “vantagens” do NoSQL podem se transformar em desvantagens. 

Os bancos de dados relacionais tradicionais há muito tempo alcançaram a novidade que alguns bancos de dados NoSQL prometiam. Eles aprimoraram enormemente sua funcionalidade de fragmentação, então você não está mais limitado a dimensionar verticalmente. Eles introduziram tipos de dados mais tolerantes; você pode armazenar JSON em PostgreSQL, MySQL, SQL Server agora, proporcionando uma experiência semelhante ao MongoDB.

Existem vários problemas com os bancos de dados NoSQL, sendo o primeiro a falta de administradores de sistemas que possam mantê-los. Implementar um banco de dados NoSQL é um esforço real e escolher o provedor e o gerente certos é difícil. Se você está em posição de precisar de um banco de dados enorme, pode estar em posição financeira para pagar por esse conhecimento, mas as empresas menores podem ter que esperar.

Além disso, entender o modelo NoSQL é difícil para os desenvolvedores acostumados com a codificação de sistemas SQL. Como grande parte da estrutura deve acontecer no aplicativo, um desenvolvedor pode entrar em um projeto dev esperando que certas restrições sejam atendidas ou que erros sejam lançados em linhas duplicadas. Em vez disso, essa lógica deve ser gerenciada no próprio aplicativo. As soluções NoSQL oferecem armazenamento de dados mais rápido e de maior desempenho, mas isso é tudo. Você, o desenvolvedor, deve intervir para gerenciar os vários relacionamentos.

Finalmente, como o NoSQL não é consistente, reversões são impossíveis se algo der errado. Além disso, algumas partes do banco de dados podem retornar informações inconsistentes - um exemplo que os especialistas oferecem é que um banco de dados SQL retornará o saldo bancário correto o tempo todo, enquanto uma solução NoSQL pode retornar um saldo diferente com base no servidor. Se isso parece assustador, você pode querer repensar sua escolha. Isso acontece na vida real quando você pesquisa pedidos em sites de comércio eletrônico como a Amazon. Em alguns casos, os dados demoram alguns segundos para aparecer porque devem ser preenchidos em toda a rede.

Acredite no hype?

Primeiro, temos que lembrar que os bancos de dados NoSQL são provavelmente ótimos para Amazon e Google, mas não tão bons para o seu lado agitado. Os benefícios de desempenho se tornam mais óbvios quanto maior for a escala de seu banco de dados. Implementá-los parece divertido e é uma ótima maneira de se familiarizar com uma tecnologia totalmente nova, mas você provavelmente poderia fazer isso lendo algumas perguntas frequentes e experimentando uma instalação do MongoDB por si mesmo. Usar uma solução NoSQL para um pequeno site de comércio eletrônico ou mecanismo de recomendação pode não funcionar tão bem. Surgiu um consenso em conferências e blogs de que SQL é o padrão ouro - com muita ênfase em PostgeSQL - e você deve usá-lo por padrão, apenas desviando se tiver bons motivos para usar NoSQL.

Dito isso, grandes empresas que precisam do tipo de velocidade que o NoSQL oferece usam esses bancos de dados, e as habilidades NoSQL estão em alta. Você pode ganhar um bom salário se puder apoiar o banco de dados NoSQL de outra pessoa. Quando estiver pronto para implementar uma solução NoSQL de sua preferência - em um projeto paralelo ou em um armazenamento de dados massivo - você estará totalmente versado nos prós e contras e, parafraseando Kenny Rogers, saberá quando para fragmentá-los, saber quando se juntar a eles, saber quando usar um esquema e quando não usar nenhum.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.