A alternativa correta é a C - certo.

Vamos analisar o tema central desta questão: os bancos de dados NoSQL e SQL. Esses dois tipos de banco de dados são fundamentais no campo de Business Intelligence (BI) e na manipulação de grandes volumes de dados.

NoSQL, como o MongoDB, foi projetado para lidar com dados não estruturados e é altamente escalável horizontalmente. Escalabilidade horizontal significa que podemos adicionar mais servidores para lidar com mais dados, o que é ideal para grandes volumes e crescimento rápido. Os bancos de dados NoSQL são geralmente usados quando a estrutura dos dados pode mudar com frequência ou quando eles são armazenados em formas não convencionais, como documentos, gráficos ou chave-valor.

Por outro lado, os bancos de dados SQL, como o MySQL, são mais adequados para dados estruturados e suportam transações ACID (Atomicidade, Consistência, Isolamento, Durabilidade). Essas propriedades são cruciais para garantir a integridade dos dados em aplicações onde as transações e a consistência são fundamentais, como em sistemas financeiros.

A questão afirma corretamente que os bancos de dados NoSQL são projetados para grandes volumes de dados não estruturados e são altamente escaláveis horizontalmente, enquanto os bancos de dados SQL são mais adequados para dados estruturados, suportando transações ACID. Portanto, a afirmação está correta, justificando o gabarito C.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

Questão linda para revisão

Bancos de dados NoSQL >> dados não estruturados

Bancos de dados SQL >> dados estruturados

Bancos de dados NoSQL NÃO SUPORTAM ACID, eles utilizam BASE como garantia no banco;

BASE = Basicamente Disponível, Estado Leve e Consistência Eventual;

EXEMPLOS DE BD NoSQL

– Cassandra: Modelo Orientado a Colunas

– Neo4J: Modelo Baseado em Grafos

– MongoDB: Modelo Orientado a Documentos

– Redis: Modelo Chave-Valor

Características mais importantes: escalabilidade, alta performance e flexibilidade.

Escalabilidade: capacidade de serem bancos de dados distribuídos em diversos clusters ou outros servidores, por conta do aumento do volume de dados. Isso tem relação com as premissas do Big Data, especificamente, com a premissa do volume.

Flexibilidade: não é rígido no seu esquema, tal como o banco de dados relacional (estrutura rígida dos dados). Quanto ao banco de dados NoSQL, embora possua o seu esquema e a sua estrutura de dados, ela é flexível, ela não é presa a uma rigidez que impede que haja mudanças, pelo contrário, é preparada para elas, justamente devido à sua flexibilidade.

BD relacionais - ORACLE, SQL Server, SQL lite e etc.

• característica ACID (não se aplica ao tipo NoSQL)

Atomicidade: Em uma transação envolvendo duas ou mais partes de informações discretas, ou a transação será executada totalmente ou não será executada, garantindo assim que as transações sejam atômicas.

Consistência: A transação cria um novo estado válido dos dados ou em caso de falha retorna todos os dados ao seu estado antes que a transação foi iniciada.

Isolamento: Uma transação não será interferida por nenhuma outra transação concorrente.

Durabilidade: Dados validados são registrados pelo sistema de tal forma que mesmo no caso de uma falha e/ou reinício do sistema, os dados estão disponíveis em seu estado correto.

Alguns SGBDs NoSQL afirmam ser "ACID compliant" (compatíveis com as propriedades ACID), e este é o caso do MongoDB. Porém, não sei afirmar se isso é totalmente correto em termos técnicos, ver abaixo, as considerações, feitas pela Amazon sobre a possibilidade de um SGBD ser simultaneamente ACID e BASE, com base no Teorema CAP.

No site do MongoDB (ver https://www.mongodb.com/resources/products/capabilities/acid-compliance), temos:

• "Podem os bancos de dados NoSQL serem compatíveis com as propriedades ACID?” A resposta é simples: com certeza! Nem todo banco de dados NoSQL é "ACID-compliant", mas muitos o são. Na realidade, o MongoDB é um banco de dados compatível com as propriedades ACID.
• A partir do MongoDB 4.0, há até suporte para transações ACID multidocumento, quando necessário.
• A versão 4.2 trouxe até transações ACID multidocumento distribuídas para ainda mais flexibilidade.

Lembro também que nem todo SGBD relacional atua como "ACID compliant". Alguns retiram esta restrição para aumentar o desempenho, no MySQL, por exemplo, as propriedades ACID são garantidas apenas quano o "storage engine" associado à tabela as implementa, como é o caso do InnoDB, já o "storage engine" MyISAM não suporta todas estas propriedades.

Já a Amazon faz uma resssalva (ver em https://aws.amazon.com/pt/compare/the-difference-between-acid-and-base-database/ ao responder a pergunta "Um banco de dados pode ser tanto ACID quanto BASE?" :

• "alguns bancos de dados NoSQL podem apresentar determinadas características ACID, mas não podem operar como bancos de dados compatíveis com ACID.

Segue o trecho extraído do site:

Um banco de dados pode ser tanto ACID quanto BASE?

De acordo com o teorema CAP, um banco de dados pode satisfazer duas das três garantias de consistência, disponibilidade e tolerância à partição. Os modelos de banco de dados ACID e BASE oferecem tolerância à partição, o que significa que eles não podem ser altamente consistentes e estar sempre disponíveis. Portanto, um banco de dados se inclina para ACID ou BASE, mas não pode ser ambos. Por exemplo, os bancos de dados SQL são estruturados no modelo ACID, enquanto os bancos de dados NoSQL usam a arquitetura BASE. No entanto, alguns bancos de dados NoSQL podem apresentar determinadas características ACID, mas não podem operar como bancos de dados compatíveis com ACID.