Como funcionam os bancos de dados NoSQL?

Ao gerenciar as informações de uma empresa, sejam elas em pequenas ou grandes quantidades, precisamos armazená-las e gerenciá-las em um local acessível e seguro, o que dá origem aos bancos de dados. A Microsoft os define como "uma ferramenta para coletar e organizar informações", pois são um armazenamento de dados inter-relacionados que nos permite usar os dados e gerenciá-los de maneira fácil e organizada.

Bancos de dados NoSQL (Not Only SQL) chamados de bancos de dados não SQL ou não relacionados, são um conjunto de dados não vinculados entre si que usam esquemas flexíveis e projetados para gerenciar grandes volumes de dados.

Um pouco de história

O termo NoSQL nasceu no início do século 21, quando surgiu a web 2.0, pois a quantidade de dados gerados pelos usuários aumentou consideravelmente. que exigia uma maneira mais flexível de gerenciá-los.

Com uma arquitetura distribuída, o NoSQL ofereceu melhor escalabilidade e desempenho diante de um grande número de consultas diárias. Acredita-se que os primeiros sistemas NoSQL a surgir foram o DynamoDB (Amazon) e o BigTable do Google.

Vantagens do NoSQL

• Redução dos custos de manutenção.
  
• Estabilidade horizontal: mais servidores podem ser adicionados em vez de exigir recursos de servidor.
  
• Permite redundância de dados.
  
• Não criam gargalos, pois, graças ao seu dinamismo, são feitos para suportar um grande número de consultas simultaneamente.
  
• Modelo de dados flexível.
  
• Facilidade de adaptação em programadores.
  

Desvantagens do NoSQL

• Suporte para instruções SQL: Eles não são totalmente compatíveis com o SQL dos bancos de dados relacionados, pois alguns usam recursos próprios.
  
• Padrão na linguagem: Geralmente os processos são feitos com diferentes sintaxes no NoSQL.
  
• Sem junções (joins). Como não estão relacionados, não podem ter junções e, se necessário, podem ser simulados com índices, para os quais seria necessário o SQL. SQL.

Quando o NoSQL deve ser usado?

Em princípio, quando sabemos que vamos consultar grandes quantidades de dados, independentemente do setor (editoras, companhias aéreas, medicina, etc.).

O NoSQL não possui esquemas ou tabelas predefinidos. Por outro lado, existem documentos onde existem coleções e nos quais podemos guardar a informação na sua exata medida, tornando-a muito flexível e, por isso, a primeira opção viável.

Em casos como uma rede social (por exemplo, Facebook), que em algum momento terá altos picos de uso por parte de seus usuários, o NoSQL é uma opção perfeita para processar esses dados, já que os dados armazenados geralmente contêm campos diferentes. Além disso, seu custo é muito baixo em comparação com bancos de dados relacionados.

Ao contrário do caso anterior, se você deseja realizar mais consultas de escrita, seria melhor avaliar a opção SQL, pois elas permitem modificar campos específicos com mais facilidade, pois possuem uma base estruturada. Por outro lado, quando são importantes validações ou tipos de dados (onde são necessárias pesquisas mais complexas), a melhor opção é, sem dúvida, recorrer a bases de dados relacionadas.

Quais empresas usam NoSQL?

McGraw-Hill: Renomada editora, fundada por James H. McGraw. Publica livros físicos e online para universidades, escolas, revistas, cientistas, etc. Tem uma presença global.

Ministério da Saúde da Turquia: Para o gerenciamento de dados neste país próspero, as autoridades usam o NoSQL, que ajuda a contabilizar mais de 77 milhões de pessoas cadastradas no sistema.

Paypal: O popular sistema de envio e recebimento de pagamentos implementa NoSQL em seus bancos de dados.

Sabre: É um dos maiores sistemas de voo do mundo. Ele usa NoSQL para armazenar seus dados sobre voos, rotas, etc. O caso desta empresa é interessante, pois graças a este sistema que remonta a 1960, a IBM e a American Airlines desenvolveram o Sabre. Foi um dos primeiros a contribuir para a evolução dos gerenciadores de banco de dados, dando origem logo depois à Segunda Geração de Bancos de Dados (SGBD).

Exemplo de NoSQL vs. SQL

Abaixo mostrarei um exemplo criando uma tabela em MySQL e MongoDB.

👉 Estarei usando MySQL Workbench 8.0 e MongoDBCompass desta vez.

Neste exemplo simples, faremos um banco de dados chamado test (prueba em espanhol). Lá teremos dados de usuário e e-mail que hipoteticamente precisamos para armazenar dados de alunos em uma universidade.

📌 Usando o MongoDB

Passo 1: Crie o banco de dados chamado teste (prueba) e a coleção chamada alunos (estudiantes).

Passo 2: Dentro da coleção de alunos, criamos dois novos:

Passo 3: Verificamos se os registros foram inseridos corretamente.

Passo 4: Para adicionar e-mails aos alunos, basta adicionar os e-mails como uma matriz. Para isso, selecionamos o aluno, clicamos no botão na parte superior direita que aparece no ícone de edição, fazemos a atualização e clicamos em update.

Podemos ver que agora os dados do aluna Lisseth foram modificados. Agora você tem dois e-mails atribuídos. Foi assim que fizemos essa mudança de forma rápida e simples.

📌 Usando o MySQL

Paso 1: Para replicar o exemplo, devemos ser claros sobre o que faremos. Para fazer isso, fazemos um diagrama ER (Entity Relationship).

Passo 2: Neste diagrama vemos que, para adicionar vários e-mails a um aluno, teremos uma relação um-para-muitos. No código ficaria assim, considerando que criamos o banco de dados de teste, depois o utilizamos, em seguida geramos as tabelas do diagrama:

Passo 3: Agora adicionamos as informações que já sabemos:

Passo 4: Verificamos se as informações estão corretas:

Aqui podemos ver que para adicionar dois ou mais e-mails à tabela dos alunos, devemos adicioná-los à tabela de e-mails, tornando-o mais complicado do que com o MongoDB.

Visualmente, notamos que os dados não podem ser vistos tão facilmente quanto no MongoDB. Aqui vemos apenas os identificadores e, portanto, é necessário ter essa informação (ao contrário do MongoDB, que nos permite ver visualmente o array na coleção).

Pelo exposto, dizemos que o MongoDB ajuda consideravelmente a escalabilidade, pois não modificamos esquemas ou outras tabelas para fazer uma alteração desse tipo. Além disso, é mais intuitivo para os desenvolvedores ver uma matriz do que um esquema de dados. Isso melhora a experiência de desenvolvimento e mais desenvolvedores estão recorrendo ao NoSQL.

Conclusão

Bancos de dados são um elemento fundamental em todo o desenvolvimento. É importante conhecê-los e, acima de tudo, diferenciá-los.

Para saber se o NoSQL deve ser implementado em nosso projeto, devemos conhecê-lo a fundo, entender os requisitos. Por exemplo, se buscamos a integridade dos dados, que sua estrutura possa ser determinada e na qual não faremos consultas de forma massiva, então utilizamos o SQL. Caso contrário, se você busca realizar consultas de leitura massiva que não possuem uma estrutura específica como em projetos de Big Data e de fontes distribuídas, o NoSQL é a escolha ideal.

Espero que este artigo tenha facilitado o aprendizado da importância e da operação atual dos bancos de dados NoSQL.

Nunca pare de aprender e praticar. Até logo! 😊