Você está na página 1de 15

UNIVERSIDADE ESTÁCIO DE SÁ

SISTEMAS DE INFORMAÇÃO

EDUARDO SANTANA CANAVARRO DO NASCIMENTO

BANCO DE DADOS NOSQL

Recife – Pernambuco
2022
EDUARDO SANTANA CANAVARRO DO NASCIMENTO, Matrícula: 201802256075

BANCO DE DADOS NOSQL

Trabalho, apresentado como parte das


exigências da disciplina de estudo dirigido,
Banco De Dados NoSQL em Sistemas de
Informação.

Recife, 07 de junho de 2022.

________________________________________
Prof. Bruno Felipe De França Souza

Recife – Pernambuco
2022
RESUMO

Este trabalho tem como objetivo a realização de uma pesquisa sobre a disciplina
Banco De Dados NoSQL, com finalidade de obter informações sobre Banco De Dados
NoSQL e o entendimento sobre a diferença de um banco relacional para um NoSQL.

Palavras Chaves: Banco; dados; NoSQL; relacional; informações; diferença.


Sumário
1. Sobre ................................................................................................................................................... 4
1.1 Para que serve? ................................................................................................................................. 4
1.2 Como é utilizado o funcionamento ................................................................................................... 5
1.3 Onde utilizar ...................................................................................................................................... 5
1.4. Tipos de bancos de dados ................................................................................................................ 5
1.4.1. Modelo Colunas ............................................................................................................................ 6
1.4.2. Modelo Grafos............................................................................................................................... 6
1.4.3. Modelo Chave-Valor...................................................................................................................... 6
1.4.4. Modelo Documento ...................................................................................................................... 6
1.5. Qual o melhor banco NoSQL? .......................................................................................................... 6
1.5.1. MongoDB....................................................................................................................................... 7
1.5.2. HBase............................................................................................................................................. 7
1.5.3. Amazon DynamoDB ...................................................................................................................... 7
1.5.4. Cassandra ...................................................................................................................................... 8
1.5.5. Redis .............................................................................................................................................. 8
2. NoSQL vs. SQL...................................................................................................................................... 8
2.1. SQL.................................................................................................................................................... 8
2.2. NoSQL ............................................................................................................................................... 9
2.3. Quais são as diferenças? .................................................................................................................. 9
3. Na prática ............................................................................................................................................ 9
3.1. JavaScript + MongoDB.................................................................................................................... 10
4. Conclusão .......................................................................................................................................... 14
4

Conteúdo do trabalho

1. Sobre
O termo NoSQL foi usado pela vez em 1998, estava relacionado com o nome de um
banco de dados não relacional. Trata-se de um grande código aberto e o seu autor
alega que o movimento NoSQL é diferente do modelo relacional. Ele defende que
era melhor ser chamado de “NoREL” ou algo parecido com isso.
A popularização da internet não estava prevista e dessa forma, foram surgindo
novos dados que precisavam de tratamento. Esse fato fez com que existisse uma
necessidade de tratar e ao mesmo tempo fazer manutenções. Os Bancos NoSQL
entram justamente nisso e o objetivo claro é deixar tudo mais fácil
É do conhecimento de todos que grande parte das aplicações de um software está
relacionado aos bancos relacionais. Algumas situações pedem que o
armazenamento de dados possa ser feito de uma forma muito mais adequada.
Essa modelagem relacional pode vir a se revelar como limitada em situações em
que o formato possa vir a ser variável. Para conseguir superar esse problema, é
preciso criar várias tabelas para atender as necessidades apresentadas.
Os Bancos NoSQL podem ser usados para garantir uma alta disponibilidade e
aumento do poder de processamento. Uma vez que com a utilização crescente da
escalabilidade, tornou-se imperdível atender isso com mais velocidade.
Os investimentos em infraestrutura podem muitas vezes vir a ser requerido e quase
sempre é algo pesado. O aspecto financeiro deve ser analisado, porque gastos
indesejados fazem com que todo o planejamento possa ser afetado.
Uma alternativa eficiente estará ligada diretamente aos Bancos NoSQL, porque ele
engloba várias opções. Como por exemplo, a capacidade que irão além das
características típicas desses sistemas de gerenciadores relacionais.

1.1 Para que serve?


NoSQL é um termo usado para bancos de dados não relacionais de alto
desempenho, onde o SQL geralmente não é usado como linguagem de consulta.
O NoSQL foi criado para ter melhor desempenho e maior escalabilidade horizontal
para a ineficácia dos bancos de dados relacionais.
5

1.2 Como é utilizado o funcionamento


O gerenciamento de dados dos bancos NoSQL se baseia em diferentes modelos
para tal atividade.
Esse modelo de banco de dados é automatizado e otimizado para servir aplicativos
que obrigam a utilização de modelos de Big Data.
Em bancos de dados relacionais, os registros de livros geralmente são mascarados
e armazenados em tabelas separadas, e os relacionamentos são definidos por
restrições de chave primária e chave estrangeira.
O modelo relacional foi projetado para permitir que os bancos de dados imponham a
integridade referencial entre as tabelas no banco de dados, normalizando para
reduzir a redundância e geralmente sejam otimizados para armazenamento.
Em bancos de dados NoSQL, os registros de livros geralmente são armazenados
como documentos JSON.

1.3 Onde utilizar


Os bancos de dados NoSQL são ideais para muitos aplicativos modernos, como
dispositivos móveis, web e jogos, que exigem um banco de dados flexível, escalável,
de alto desempenho e poderoso para fornecer uma ótima experiência ao usuário.
- Flexibilidade: Os bancos de dados NoSQL geralmente fornecem esquemas
flexíveis para um desenvolvimento iterativo mais rápido;
- Um modelo de dados flexível torna os bancos de dados NoSQL ideais para dados
semiestruturados e não estruturados;
- Escalabilidade: os bancos de dados NoSQL geralmente são projetados para
escalar usando clusters de hardware distribuídos, em vez de adicionar servidores
caros e poderosos;
- Alguns provedores lidam com essas operações nos bastidores como serviços
totalmente gerenciados;
- Alto desempenho dos bancos de dados NoSQL: são otimizados para modelos e
padrões de acesso de dados de modelos, resultando em desempenho superior ao
desempenho de funções semelhantes com bancos de dados relacionais;
- Poderoso: os bancos de dados NoSQL podem fornecer tipos e dados de dados
criados especificamente para seus respectivos modelos de dados.

1.4. Tipos de bancos de dados


Quanto aos tipos de bancos de dados que podem ser utilizados, pode-se ser citados
alguns modelos de bancos dados NoSQL.
6

1.4.1. Modelo Colunas


No modelo de coluna, o banco de dados é armazenado em uma linha específica da
tabela. Esse padrão é exatamente o oposto dos bancos de dados relacionais, que
armazenam conjuntos de dados em uma linha.

1.4.2. Modelo Grafos


Armazenar dados em forma de gráfico. Ou seja, os dados aqui são organizados na
forma de arcos conectados por arestas. Também podemos defini-lo como um conjunto
de linhas conectadas por vértices.
Diante de buscas complexas, os modelos gráficos são vantajosos, por exemplo,
espera-se que a latência e o desempenho sejam inferiores aos modelos de valor-
chave.

1.4.3. Modelo Chave-Valor


Em modelos de chave-valor, o banco será formado por várias chaves, que são
acompanhadas de valores.
A estrutura desse modelo chave-valor é bastante flexível, adequada e padronizada
para armazenamento de Big Data. Notavelmente, este formato é altamente utilizável.

1.4.4. Modelo Documento


Neste modelo, os dados são em formatos de documentos. Este modelo é muito flexível
e não necessita de colunas pré-montadas.
Esse modelo é particularmente eficaz para trabalhar com dados não estruturados, pois
uma única coleção pode conter muitos grupos de documentos em diferentes formatos.

1.5. Qual o melhor banco NoSQL?


Os bancos de dados NoSQL referem-se a muitas tecnologias diferentes que não são
de natureza relacional.
Será apresentado alguns dos modelos mais conhecidos.
7

1.5.1. MongoDB
O modelo MongoDB é o líder de mercado em bancos de dados NoSQL.
Ele também tem alguns recursos de produção sofisticados e modernos. São eles:
replicação, indexação, balanceamento de carga.
O mais importante, e talvez a razão pela qual é líder de mercado, é que o MongoDB
é de código aberto, o que contribuiu muito para a evolução de sua tecnologia.

1.5.2. HBase
O 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 escrito em Java. É por isso
que se integra facilmente com o MapReduce.
Para quem não sabe, MapReduce é 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. Converta terabytes em milissegundos.

1.5.3. Amazon DynamoDB


Mais um ótimo produto da AWS (Amazon Web Services). Os bancos de dados do
DynamoDB são totalmente baseados em nuvem para um desempenho confiável em
escala.
Vale ressaltar que a Amazon confirma que a latência é consistente e mantida abaixo
de 10ms.
Além disso, 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.
8

1.5.4. Cassandra
Muita gente não sabe, mas o Cassandra foi desenvolvido no Facebook. Hoje, o
Cassandra, assim como o HBase, é mantido pela Apache Foundation.
Isso até faz sentido dada a quantidade de dados que as redes sociais geram a cada
milissegundo.
Mas, afinal, por que o Cassandra é tão popular no processamento de big data?
Na verdade, o Cassandra é muito otimizado para clusters, especialmente porque
funciona sem um mestre. O fato de ter um mecanismo distribuído também otimiza
bastante a operação do cluster.
Outra vantagem do Cassandra é o conceito de orientação de coluna, que faz com que
certas consultas tenham latência muito menor.

1.5.5. 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.

2. NoSQL vs. SQL


Existem várias comparações de desempenho realizadas entre ele e o SQL, tendo
como a velocidade o fator mais importante na decisão de qual banco utilizar. Há muitas
opções de bancos de dados NoSQL com diferentes funcionalidades que podem ser
muito úteis. Mas como decidir entre um banco de dados relacional e um não-
relacional?

2.1. SQL
SQL é a sigla para “Structured Query Language” que significa, traduzindo para o
português, “Linguagem de Consulta Estruturada”. Trata-se de uma linguagem de
consulta a banco de dados relacionais. Com o SQL, você pode executar vários
comandos para criar, alterar, gerenciar, consultar, dentre outras informações no seu
banco de dados. Assim os bancos SQL seguem uma modelagem relacional, pois
estes se baseiam no fato de que todos seus dados sejam guardados em tabelas.
9

2.2. NoSQL
O conceito de modelo relacional (SQL) se baseia no fato de que todos os dados
sejam guardados em tabelas. Ao modelo não-relacional (NoSQL) não se aplica o
conceito de schema: uma chave de valor é que é utilizada para recuperar valores,
conjunto de colunas ou documentos. Sendo assim, acaba sendo um banco mais
prático e flexível para tomada de decisões mais variadas.

2.3. Quais são as diferenças?


Uma das diferenças nos bancos de dados NoSQL é que toda a informação é agrupada
e guardada no mesmo registro. Isso pode trazer certa flexibilidade e rapidez na hora
de criação do banco de dados. Já no SQL você precisa ter o relacionamento entre
várias tabelas para ter a informação, está disposta no modelo entidade e
relacionamento o que pode causar certa dor de cabeça pelas partes envolvidas.
O SQL tem certa dificuldade em conciliar a demanda por escalabilidade. Quanto a
escalabilidade do NoSQL, deve se levar em consideração a modelagem do sistema.
Do que adianta termos um sistema supersimples e querermos utilizar o NoSQL
apenas pela escalabilidade? Todo o ganho de performance seria perdido quando
rodássemos a aplicação.
Um ponto forte do SQL é quanto à consistência das informações. Já o NoSQL garante
o último valor atualizado, isso se nenhuma atualização for realizada até o momento
da consulta.
Em um sistema de loja, por exemplo, é muito mais pratico se utilizar um bando de
dados NoSQL do que um SQL, pois os produtos variam muito em suas informações e
características, o que acaba dificultando a implementação em um banco de dados
relacional (SQL).
Quanto à segurança, ambos estão suscetíveis a ataques.

3. Na prática
Botando a mão na massa, foi utilizado um dos programas de banco de dados que foi
informado. O MongoDB junto com JavaScript para poder demonstrar como o banco
de dados se comporta.
10

3.1. JavaScript + MongoDB


No JavaScript foi criando uma simples programação para cadastro de pessoas ou
empresas para demonstrar o uso do banco de dados noSQL. Nele contém o script
para receber o cadastro, editar, listar e excluir os registros. Segue o script, a parte
do app.js:
const createError = require('http-errors');
const express = require('express');
const mongoose = require('mongoose');
const path = require('path');
const cookieParser = require('cookie-parser');
const logger = require('morgan');

const indexRouter = require('./routes/index');


const usersRouter = require('./routes/users');

require("./models/Artigo");
const Artigo = mongoose.model('artigo');

const app = express();

app.use(express.json());

mongoose.connect('mongodb://localhost/db', {
useNewUrlParser: true,
useUnifiedTopology: true
}).then(() => {
console.log("Conexão realizada com sucesso!");
}).catch((erro) => {
console.log("Error: Conexão não foi realizada com sucesso!")
});

app.get("/", (req, res) =>{


Artigo.find({}).then((artigo) =>{
return res.json(artigo);
}).catch((erro) =>{
return res.status(400).json({
error: true,
message: "Nenhum artigo encontrado!"
});
});
});

app.get("/artigo/:id", (req, res) => {

Artigo.findOne({_id:req.params.id}).then((artigo)=>{
return res.json(artigo)
}).catch((erro) => {
11

return res.status(400).json({
error: true,
message: "Nenhum artigo encontrado!"
});
});

});

app.post("/artigo", (req, res) => {


const artigo = Artigo.create(req.body, (err) => {
if(err) return res.status(400).json({
error: true,
message: "Error: Artigo não foi cadastrado!"
})

return res.status(200).json({
error: false,
message: "O artigo foi cadastrado com sucesso!"
});
});
});

app.put("/artigo/:id", (req, res) =>{


const artigo = Artigo.updateOne({_id: req.params.id}, req.body, (err) =>{
if(err) return res.status(400).json({
error: true,
message: "Error: Artigo não foi editado!"
});

return res.json({
erro: false,
message: "Artigo editado com sucesso!"
});
});
});

app.delete("/artigo/:id", (req, res) => {


const artigo = Artigo.deleteOne({_id: req.params.id}, (err) => {
if(err) return res.status(400).json({
error: true,
message: "Error: Artigo não foi apagado!"
});
return res.json({
error: false,
message: "Artigo apagado com sucesso!"
});
});
});
12

app.listen(8080, () =>{
console.log("Servidor iniciado na porta 8080: http://localhost:8080")
});

// view engine setup


app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');

app.use(logger('dev'));
app.use(express.json());
app.use(express.urlencoded({ extended: false }));
app.use(cookieParser());
app.use(express.static(path.join(__dirname, 'public')));

app.use('/', indexRouter);
app.use('/users', usersRouter);

// catch 404 and forward to error handler


app.use(function(req, res, next) {
next(createError(404));
});

// error handler
app.use(function(err, req, res, next) {
// set locals, only providing error in development
res.locals.message = err.message;
res.locals.error = req.app.get('env') === 'development' ? err : {};

// render the error page


res.status(err.status || 500);
res.render('error');
});

module.exports = app;

Já no Artigo.js ficou assim:

const mongoose = require('mongoose');

const Artigo = new mongoose.Schema({


tipo: {
type: String,
required: true
},
nome: {
type: String,
required: true
13

},
cidade: {
type: String,
required: true
},
estado: {
type: String,
required: true
},
bairro: {
type: String,
required: true
},
email: {
type: String,
required: true
},
genero: {
type: String,
required: true
}
},
{
timestamps: true,
});

mongoose.model('artigo', Artigo);

Dentre as partes do script, essas são as mais importantes para o programa


funcionar, terá mais detalhes no arquivo que será enviado junto com essa
documentação.
14

4. Conclusão
O NoSQL tem muitas vantagens para ser utilizado. Mas não é por isso que devemos
utilizá-lo em todas as situações. Em muitos sistemas, você pode (e até deve) usar o
modelo relacional. O NoSQL é mais indicado para aqueles sistemas que tenham
necessidades maiores de armazenamento e desempenho.
O NoSQL não veio para substituir o SQL, mas sim para oferecer mais uma
alternativa de um banco de dados mais flexível no suporte de dados. Sendo assim,
você pode usar ambas as soluções para diferentes casos de uso. Por isso, o mais
comum em soluções escalares de sucesso é a utilização de uma arquitetura híbrida,
aproveitando o melhor dois modelos.

Você também pode gostar