SQL ou NOSQL: qual mais adequado para o seu projeto ?
- #SQL Server
- #PostgreSQL
- #NoSQL
- #MongoDB
- #SQL
Estive pensando sobre pontos onde optar pelos dois modelos tendo em vista um panorama geral onde temos diversas ferramentas maduras tanto para um modelo quanto para o outro. No entanto, quando há um time qualificado para lidar com ambos, pode ser feita uma escolha arquitetural, e baseado em requisitos do projeto, optar pela ferramenta que melhor se adequar a necessidade. Porém quais pontos devem ser observados?
Segundo teorema de Brewer(teorema CAP), todo sistema distribuído pode apenas ter duas de três garantias.
- Consistência: Toda leitura recebe a informação mais recente ou um erro. Assim garantindo que todos os clientes obtêm a mesma resposta ao mesmo tempo.
- Disponibilidade: Toda request recebe a uma resposta, e não deve falhar. Sem garantir que é a versão mais recente dos dados.
- Tolerância de partição: O sistema continua a operar independentemente do número de mensagens.
Quando uma partição falhar, o sistema deve decidir por uma das opções:
- Cancelar a operação, assim afetando a disponibilidade.
- Proceder com a operação, e assim promovendo disponibilidade, porém com risco de existir inconsistência. Sendo que não necessariamente essa disponibilidade vai se refletir como disponibilidade para os usuários, situação que pode depender do tipo de problema que gerou a inconsistência.
E o teorema também discorre sobre pontos já conhecidos, como nenhum sistema online está livre de ter problemas de internet, e tolerância de partições costuma ser mandatório em sistemas distribuídos.
Restando assim a possibilidade de escolha apenas entre Consistency, e Availability, pois o Partition já estaria sendo demandado só pelo fato de o sistema ser distribuído.
Então é comum haver associações com a lógica do teorema quando pensamos em optar por um ou outro sistema de bancos, pois os SQL foram construídos priorizando consistência, seguindo um design aderente ao ACID enquanto NOSQL surgiram aderindo ao design do BASE. E embora as ferramentas atualmente disponíveis para o NoSQL e SQL tenham amadurecido ao longo dos anos, diminuindo as limitações de consistência e de disponibilidade, ainda possuem diferenças de performance, consistência de dados, disponibilidade e sintaxe.
Alguns pontos focados no uso dessas tecnologias no dia a dia, como destaque, há cenários onde os dados são na maior parte conhecidos e bem estruturados, e outros nem tanto. Por exemplo, alguns casos de uso que são amplamente difundidos como bancos e e-commerce. Porém haverá situações em que o usuário pode necessitar consumir dados em larga escala, ou armazenar logs de um sistema, e pode necessitar de outros modelos flexíveis para experimentação ao longo do tempo.
Então quando podemos usar um ou outro? Aqui vou tentar dizer alguns pontos principais:
SQL
- Transações (ACID).
- Autenticação
- Cenário de requisitos claros.
- Dados estruturados (Normalização, dados sem repetição).
- Prioriza consistência.
NoSQL
- Dados sem normalização, permitem a repetição de informações em tabelas.
- Cenário que admite ou necessita de flexibilidade.
- Necessidade de escala rápida.
- Prioriza a disponibilidade.
Dito isso, já exemplificamos os principais cenários, também gostaria de acrescentar que a combinação das duas ferramentas dentro da arquitetura de um mesmo projeto, pode fornecer o melhor dos dois cenários. Portanto acredito que faça sentido uma combinação de bancos de dados diferentes de acordo com a arquitetura de cada projeto, onde um cliente necessita de acesso a dados de pedidos, e precisa estar logado na aplicação, talvez faça sentido guardar dados do cliente em uma tabela de SQL para esses casos, enquanto isso mensagens de chats de um serviço de atendimento ao cliente poderiam ser armazenadas em bancos NoSQL, é possível admitir que algumas das transações dessas informações passem por microsserviços no decorrer da informação, as vezes até com o objetivo de fornecer maior disponibilidade para os clientes garantindo o atendimento sempre que estivessem disponíveis, e com isso o banco pode ser beneficiar de bancos NoSQl para ter alguns registros de logs de autenticação, pedido e localidade onde foi acessado, e posteriormente conferir os produtos em um SQL e registrar as conversas.
Fontes:
SQL e NoSQL: entenda bancos relacionais e não relacionais | Alura Entenda Teorema CAP - DEV Community CAP theorem - Wikipedia Quando usar SQL e NoSQL: Um guia para a escolha certa | LinkedIn
