SQL ou NoSQL: Qual é a melhor escolha para sua aplicação?

#Banco de dados relacional

SQL ou NoSQL: Qual é a melhor escolha para sua aplicação?

Escolher entre SQL e NoSQL é fundamental em projetos. Vamos explorar essa escolha e responder à pergunta: uma empresa pode utilizar ambos? Vamos descobrir juntos essa e outras inúmeras dúvidas.

Introdução: SQL vs NoSQL - O Confronto de Titãs

Sempre que pensamos em guardar dados nos vem à mente banco de dados e logo em seguida aprender SQL e não é por menos quem inventou e desenvolveu foi a IBM que conseguiu provar que é possível implementar bancos de dados relacionais práticos e que o SQL era uma linguagem utilizável para manipulá-los.

Diferentes implementações do SQL surgiram devido a preocupações com desempenho, competição e aproveitamento de recursos específicos de hardware ou software. Para manter essas diferenças controladas, um comitê de padronização foi criado nos anos 1980.

O comitê, X3H2, patrocinado pelo instituto Nacional de Padrões Americano (ANSI), emitiu o padrão SQL1 em 1986.

Este padrão define um conjunto central de recursos do SQL. Ele também define a sintaxe de declarações como SELECT e é interessante notar que o SQL foi inspirado na álgebra relacional.

O SGBD permite armazenar, modificar e extrair dados de um banco de dados fornecendo funções como validação recuperação de falhas, segurança, otimização de consultas e garantia da integridade dos dados

SGBDs Relacionais permitem múltiplos usuários acessarem e manipularem um banco de dados simultaneamente de forma eficiente em sistemas de grande porte. Os SGBDs possuem a capacidade de recuperação de falhas, garantindo a consistência do banco de dados ao voltar, ao ponto anterior da falha.

Bancos de dados relacionais seguem o modelo ACID para preservar a integridade de uma transação, sendo divididos em quatro propriedades.

Atomicidade: As ações que compõem uma transação devem ser concluídas com sucesso para que a transação seja efetivada. Se a transação falhar, será realizado um rollback.
Consistência: Todas as regras e restrições descritas no banco de dados devem ser obedecidas, garantindo que o banco de dados mantenha sua consistência.
Isolamento: Neste caso, a propriedade de isolamento garante que a transação não será interferida por nenhuma outra transação concorrente.
Durabilidade: Os resultados de uma transação são permanentes, ou seja, o que foi salvo não será mais perdido.

Todos esses recursos garantem aos SGBDs Relacionais a posição de predominância entre os mais diversos tipos de ambientes computacionais. Porém, mesmo com os cuidados, os problemas foram surgindo, principalmente devido ao grande crescimento do volume de dados presentes nos bancos de dados.

Nos últimos anos, a big data tem atingido inúmeras empresas e não apenas as gigantes, como anteriormente.

Limitações dos bancos de dados relacionais

Atualmente os dados estão em ritmo acelerado de expansão, alguns exemplos como:

O Facebook gera 4 petabytes de dados por dia (1 milhão de gigabytes), ou seja, em um mês gera uma média de 120 petabytes por mês, e sua base de dados possui 300 petabytes de dados.

É estimado que o YouTube em 2022 gerou mais de 77 Exabytes mensais

A utilização de SGBDs relacionais tem se mostrado muito problemática e não tão eficiente. Vamos usar um exemplo: imagine a empresa em que você trabalha, e ela possui um sistema SGBD relacional, e a mesma tem o foco de receber mais usuários a cada dia.

Quando há um número exponencial no número de usuários em sistemas que utilizam SGBD relacional, a performance tende a diminuir.
Existe duas soluções de escalabilidade que parecem ser efetivas:
Escalabilidade vertical:
Realizar um upgrade no servidor, incluindo mais memória, processadores e armazenamento
Escalabilidade horizontal:
Adicionar mais servidores.
Se o crescimento de usuários continuar, essas soluções podem não ser suficientes.
Os custos se tornarão elevados e o projeto inviável.
O modelo relacional está focado nos relacionamentos entre as entidades, tornando as mudanças “burocráticas”.

Uma nova geração de Bancos de dados vem crescendo e ganhando o seu merecido destaque os NoSQL (“Not Only SQL”). Neste artigo iremos analisar cirurgicamente o NoSQL.

NoSQL – Assegure-se, pois, velocidade da luz é algo rotineiro

O termo NoSQL surgiu em 1998 para descrever sistemas que não usavam SQL e não ofereciam uma interface SQL, embora ainda fossem baseados no Modelo Relaciona. Com o tempo passou a utilizar a abreviação Not Only SQL(Não apenas SQL).

O objetivo não é extinguir o Modelo Relacional, mas utilizá-lo onde é necessário a flexibilidade na estruturação do banco. E o movimento NoSQL ganhou força com as gigantes do mercado como:

Google
BigTable – desenvolvido em 2004
Objetivo: Foco em alto desempenho, escalabilidade e disponibilidade.
Facebook
Cassandra
Objetivo: Lidar com volumes massivos de informações.
Twitter em 2010
Substitui o MySQL pela Cassandra
Objetivo: Melhorar a sua eficácia.

Embora todos sejam NoSQL, não são completamente iguais possuindo semelhanças e muitas particularidades que os fazem ser único, é como uma casa todas tem algo em comum, mas nenhuma é igual a outra.

Agora irei falar da principal vantagem.

Escalabilidade Horizontal:
Os bancos de dados relacionais não escalam com facilidade, pois os processos se conectam simultaneamente em u mesmo conjunto de dados gerando uma alta concorrência e assim aumenta o tempo de acesso às tabelas.

Enquanto nos bancos NoSQL é justamente a ausência de bloqueios, o que permite a estabilidade horizontal com uma maior ficaria. Pois ele não é afetado pela concorrência.
O método Sharding divide os dados em múltiplas tabelas a serem armazenadas ao longo de diversos nós na rede, resumidamente essa técnica faz é romper a cadeia de relacionamentos.

Bancos de dados relacionais podem ser feito o método Sharding porém é algo complexo para ser implementado que está desenvolvendo.
Ausência de esquema (Schema-free) ou esquema flexível:
A ausência parcial ou total do esquema que define a estrutura de dados é algo que facilita a alta escalabilidade e alta disponibilidade, mas em contrapartida não há a garantia de integridade dos dados.
Suporte Nativo a replicação:
Ao permetir a replicação de forma nativa o tempo gasto para recuperar informações é reduzido.
API simples para acessar o banco de dados.
O foco não é armazenar dados e sim como recuperar os dados de forma eficiente com isso o fundamental é o desenvolvimento de APIs para facilitar o acesso às devidas informações de forma rápida e eficiente.
Consistência eventual:
Nem sempre a consistência de dados é mantidade e isso tem embasamento no teorema CAP (Consistency, Availability e Partition tolerance).

Em um dado momento só é possível garantir duas destas três propriedades que seriam Consistência, Disponibilidade e Tolerância à partição.
No mundo real, as últimas duas do CAP são privilegiadas.

As propriedades do ACID não são respeitadas simultaneamente, ao contrário disto, temos outro conjunto de projetos denominado BASE(Basicamente disponível, Estado leve e Consistente em momento determinado)

É preciso ter planejamento para que o sistema possa tolerar inconsistências temporárias com o objetivo de priorizar a disponibilidade.

É importante ressaltar algumas técnicas utilizadas para a implementação de suas funcionalidades.

Map/Reduce: Permite o processamento de grandes volumes de dados distribuídos em uma rede.
Na fase “map”, os problemas são divididos em partes menores e distribuídos em nós da rede.
Na fase “Reduce”, esses problemas menores são resolvidos em cada nó e os resultados são passados de volta até chegar ao nó raiz, resolvendo o problema principal.
Esse modelo é eficaz para lidar com grandes conjuntos de dados distribuídos.

Vamos usar o MongoDB (banco NoSQL) como base para explicar

mapReduce obsoleto no MONGO db

Agora vamos mostrar a nova versão que o Mongo sugere para substituir o MapReduce.

O pipeline de agregação é uma estrutura para agregação de dados modelada no conceito de pipelines de processamento de dados. Os documentos entram em um pipeline de vários estágios que os transforma em resultados agregados.

Consistent Hashing: pode ser usado em sistemas distribuídos para compartilhar a carga entre os nós e diminuir os efeitos das falhas dos nós. Por exemplo, quando um novo nó é adicionado à rede, apenas um pequeno número de chaves é remapeado para o novo nó, o que ajuda a reduzir a sobrecarga associada à adição.

É claro que isso é apenas uma introdução superficial e renderia artigos separados só das pipelines de agregação e do consistent Hashing pois é assunto muito extenso.

MVCC (Multiversion concurrency control): Oferece suporte a transações paralelas em banco de dados. Por não fazer uso de locks para controle de concorrência, faz com que transações de escrita e leitura sejam feitas simultaneamente.

Vector clocks: Ordenam eventos que ocorreram em um sistema. Como existe a possibilidade de várias operações estarem acontecendo simultaneamente, o uso de um log de operações informando suas datas se faz importante para informar qual versão de um dado é a mais atual

Considere um processo (P) com tamanho vetorial N para cada processo: o conjunto de regras mencionado acima deve ser executado pelo relógio vetorial:

O exemplo acima mostra o mecanismo de relógios vetoriais em que os relógios vetoriais são atualizados após a execução de eventos internos, as setas indicam como os valores dos vetores são enviados entre os processos (P1, P2, P3).

Resumindo, algoritmos de relógios vetoriais são usados em sistemas distribuídos para fornecer uma ordenação de eventos causalmente consistente, mas o vetor inteiro é enviado a cada processo para cada mensagem enviada, a fim de manter os relógios vetoriais sincronizados.

Escalonamento
Banco de Dados Relacional
É importante lembrar que é possível ser feito o escalonamento em um Modelo Relacional, no entanto, é muito complexo. Possui uma natureza estruturada, portanto, a inserção dinâmica e transparente de novos nós a tabela não é realizada naturalmente.
Banco de Dados NoSQL
Não possui um esquema pré-definido fazendo com que este tipo de modelo seja flexível o que favorece a inserção transparente de outros elementos.
Consistência
Banco de Dados Relacional
Neste quesito, o Modelo Relacional se mostra forte. As suas regras de consistência são bastante rigorosas no que diz respeito à consistência das informações.
Banco de dado NoSQL
Atualização nos dados, todos os acessos aos itens devolverão o último valor que foi atualizado.
Disponibilidade
Banco de dados
Por não conseguir trabalhar de forma eficiente com a distribuição de dados, o Modelo Relacional acaba não suportando uma demanda muito grande de informações.
Banco de dado NoSQL
Outro ponto forte neste modelo é o que diz respeito à disponibilidade, pois possui um alto nível de distribuição de dados, permitindo assim que seja possível fazer com que um enorme fluxo de solicitações aos dados seja atendido com a vantagem do sistema ficar indisponível o menor tempo possível.

Qual o melhor banco NoSQL?

Os bancos de dados NoSQL referem-se a muitas tecnologias diferentes que não são de natureza relacional.

Os modelos de banco NoSQL mais populares do mercado

• MongoDB

• Quando se pensa em banco NoSQL MongoDB é sempre o foco.

• Possui recursos de produção sofisticados e modernos entre eles: replicação, indexação, balanceamento de carga.

• A chave de ouro é que o MongoDB é de código aberto, o que contribuiu muito para a evolução de sua tecnologia.

• Amazon DynamoDB

• Um excelente produto da AWS (Amazon Web Services). O DynamoDB são totalmente baseados em nuvem para um desempenho confiável em escala.

• Amazon confirma que a latência é consistente e mantida abaixo de 10ms.

• Possui valiosos recursos de segurança baseados em cache de memória, backup e recuperação de dados.

• O DynamoDB também pode trabalhar com vários mestres.

• O banco de dados é amplamente usado, assim como o MongoDB, para criar armazenamento de dados, jogos, tecnologia de anúncios e aplicativos da Web sem servidor.

• Cassandra

• Como comentado no inicio deste artigo Cassandra foi desenvolvido no Facebook e atualmente é mantido pela Apache Foundation.

O que faz da Cassandra tão especial e popular em processamento de big data?

O foco da Cassandra é a otimização máxima em relação a clusters com a vantagem de funcionar sem um mestre e ainda ter um mecanismo distribuído também otimiza bastante a operação do cluster.

E um trunfo da Cassandra é o conceito de orientação de coluna, que faz com que certas consultas tenham latência muito menor.

• Redis

• Redis é um modelo de armazenamento de dados de código aberto e lançado em 2009. Os dados são armazenados na memória Redis na forma de valor-chave, que é rápido e flexível.

• Este é o banco de dados NoSQL do tipo chave-valor mais conhecido.

• Como os dois primeiros, o Redis tem latência muito baixa. Redis também é fácil de usar e muito rápido.

• HBase

• É um banco de dados distribuído orientado a colunas de código aberto. Atualmente, Spotify e Facebook são algumas das grandes empresas que utilizam esse modelo de armazenamento.

• O HBase é formatado a partir do BigTable do Google e também escrito em Java. É por isso que se integra facilmente com o MapReduce.

MapReduce(Não confunda com o abordado anteriormente que pertence ao MongoDB) é uma ferramenta do framework Apache Hadoop, uma das principais plataformas para processamento de big data.

Como parte do projeto Apache, diretamente relacionado à ciência de dados, o HBase é outro modelo de armazenamento muito conhecido.

Um de seus pontos fortes é que ele fornece pesquisas de dados rápidas e responsivas.

Convertendo terabytes em milissegundos.

Conclusão

A maneira como você armazena e gerencia os dados faz total diferença. É aqui que entram os Bancos de Dados NoSQL e SQL. Eles são como super-heróis do mundo dos dados, cada um com suas habilidades únicas.

Se você deseja velocidade e escalabilidade espetaculares, escolha NoSQL. É perfeito para aplicativos de rápido crescimento e interações em tempo real.

Se você valoriza a integridade e precisa de consistência, vá de SQL. É a escolha ideal para sistemas críticos que não podem falhar.

É aquilo cada um brilha em seu próprio cenário

Agradeço a todos que leram até aqui e uma ultima pergunta quem deve ganhar o seu coração?

Deixe um comentário e logo em seguida diga de qual time você é?

#SQL

#NoSQL

#DBUniao

Em última análise, a escolha depende das suas necessidades. Mas não se preocupe, você não precisa escolher apenas um. Muitas empresas combinam ambos para obter o melhor dos dois mundos. Afinal, heróis diferentes podem trabalhar juntos para salvar o dia!

SQL ou NoSQL: Qual é a melhor escolha para sua aplicação?

SQL ou NoSQL: Qual é a melhor escolha para sua aplicação?

Introdução: SQL vs NoSQL - O Confronto de Titãs

Limitações dos bancos de dados relacionais

NoSQL – Assegure-se, pois, velocidade da luz é algo rotineiro

Qual o melhor banco NoSQL?

Conclusão

Referências