SlideShare uma empresa Scribd logo
1 de 15
Baixar para ler offline
DISCIPLINA
BANCO DE DADOS II
PROFESSOR: PETRONIO CANDIDO

NOSQL
BASE X ACID
TEOREMA CAP

ARICELIO DE SOUZA FERNANDES
3º PERIODO

JANUÁRIA
JUNHO DE 2013
SUMÁRIO
1.1 INTRODUÇÃO ............................................................................................. 02
2.1 NOSQL .......................................................................................................... 02
2.2 PRINCIPAIS CARACTERÍSTICAS ............................................................ 03
2.3 TÉCNICA PARA IMPLEMENTAÇÃO....................................................... 04
2.4 PRINCIPAIS TIPOS ..................................................................................... 05
2.5 BANCO DE DADOS CHAVE-VALOR ...................................................... 05
2.6 BANCO DE DADOS ORIENTADO A COLUNAS .................................... 05
2.7 BANCO DE DADOS ORIENTADO A DOCUMENTOS ........................... 06
2.8 BANCO DE DADOS ORIENTADO A GRAFOS ....................................... 06
3.1 BASE X ACID .............................................................................................. 07
4.1 TEOREMA CAP ........................................................................................... 08
5.1 PARA QUE É INDICADO O NOSQL? ....................................................... 10
6.1 PRINCIAPAIS PRODUTOS NO MERCADO............................................. 10
7.1 PRINCIPAIS UTILIZADORES DO NOSQL .............................................. 10
8.1 INSTALAÇÃO DO BANCO DE DADOS MYSQL NDB CLUSTER ....... 10
9.1 CONCLUSÃO ............................................................................................... 13
10.1 REFERENCIAS BIBILOGRÁFICAS .......................................................... 14
1.1

INTRODUÇÃO
Bancos de dados relacionais hoje são a tecnologia predominante para
armazenar dados estruturados, tanto em aplicações dentro da web como fora dela. A
partir de 1970 o armazenamento de dados baseado em cálculo relacional foi
amplamente adotado e muitos pensaram ser a única alternativa para o armazenamento
de dados acessível por vários clientes de uma forma consistente.
Nos últimos anos, o pensamento sobre como armazenar grandes quantidades
de dados tem sido bastante questionado, e isso levou ao surgimento de uma grande
variedade de alternativas. O movimento, bem como as novas formas de
armazenamento de dados foram agrupados sob o termo de NoSQL (Not Only SQL),
bancos de dados não-relacionais.
O termo NoSQL foi usado pela primeira vez em 1998 para um banco de dados
relacional que omitiu o uso de SQL. O termo foi usado novamente em 2009 em
conferências de defensores de banco de dados não-relacionais.
A revista americana Computer World afirmou em um de seus artigos que os
bancos de dados não-relacionais vieram para acabar com a tirania dos lentos e caros
bancos de dados relacionais, com formas mais eficientes e mais baratas de
gerenciamento de banco de dados. A exemplo temos o Cassandra - Originalmente foi
desenvolvido para um recurso do Facebook, que de acordo com o engenheiro Avinash
Lakshman tem o poder de escrever 2500 vezes mais rápido em um grande banco de
dados de 50 Gb do que o MySQL.
Uma das principais vantagens no uso de bancos de dados não-relacionais está
no fato de sua utilização horizontal, ou seja, a distribuição de dados através de bancos
disseminados em diferentes servidores, ao contrário do padrão dos bancos mais
utilizados e relacionais (MySQL, MS SQL Server, PostgreSQL, etc.), em que é
necessário promover o seu crescimento verticalizado.

2.1

NOSQL
NoSQL (Not Only SQL) significa “Não Apenas SQL”, esse termo referencia
a Sistemas de Gerenciamento de Banco de Dados (SGBDs) que não adotam o modelo
relacional (daí o nome Bancos de Dados Não-Relacionais) e são mais flexíveis quanto
ás propriedades ACID. Esta flexibilidade é necessária devido aos requisitos de alta
escalabilidade para o gerenciamento das grandes quantidades de dados e a alta
disponibilidades dos mesmos.
Como já abordado, o termo NoSQL engloba todos os tipos de bancos de dados
não-relacionais, e foi criado com o objetivo de atender aos requisitos de gerenciamento
de grandes volumes de dados, semi-estruturados ou não estruturados, que necessitam
de alta disponibilidade e escalabilidade.
A necessidade de se criar esse novo tipo de banco de dados, nasceu devido
aos bancos de dados tradicionais não conseguirem atender a esses requisitos. Os banco
de dados relacionais nasceram na década de 70, quando as aplicações de banco de
dados lidavam com dados estruturados, e também vale ressaltar que o volume dos
dados gerados naquela época nem se compara com o volume de dados gerados pelas
redes sociais atualmente. Assim as empresas que hoje trabalham com grandes volumes
de dados e precisam de uma alta disponibilidade e escalabilidade dos mesmos,
adotaram a essa nova tecnologia, podemos citar como exemplo a Google, Amazon,
Facebook e LinkeIn.
Alguns bancos de dados NoSQL fornecem maior taxa de transferência de
dados do que os bancos tradicionais. Como por exemplo o Google consegue processar
20 Petabytes por dia armazenadas em BigTable. Os bancos de dados NoSQL são
projetados para escalar bem em direção horizontal e não depender de hardware. Assim
as máquinas podem ser adicionadas ou removidas sem nenhum problema.
2.2

PRINCIPAIS CARACTERÍSTICAS
Os Banco de Dados NoSQL tem algumas características que os diferenciam
dos banco de dados tradicionais, essas características são de suma importância para o
armazenamento adequado de grandes volumes de dados não estruturados ou semiestruturados, dentre essas características podemos citar:
 Escalabilidade Horizontal: A medida que um volume de dados cresce, é
necessário que se aumente a escalabilidade, para que o desempenho não caia.
Para solucionar esse problema temos dois tipos de escalabilidade, a
escalabilidade vertical e a escalabilidade horizontal. A escalabilidade vertical
consiste em aumentar o poder de processamento e armazenamento das
máquinas. Já a escalabilidade horizontal consiste em aumentar o número de
máquinas disponíveis. Analisando os dois tipos de escalabilidade, o mais
viável tende a ser a escalabilidade horizontal, porém esse tipo de escalabilidade
requer que vários processos de uma tarefa sejam criados e distribuídos, ou seja
quando uma tarefa for iniciada ela será dividida em processos e distribuída
pelas máquinas. Usar um banco de dados relacional com esse tipo de
escalabilidade seria inviável, porque uma vez que diversos processos
conectando uma ao mesmo tempo um conjunto de dados causaria uma alta
concorrência, aumentando o tempo de acesso ás tabelas envolvidas. Uma
característica fundamental dos bancos de dados NoSQL é a ausência de
bloqueios, isso permite que a escalabilidade horizontal se torne uma tecnologia
adequada para a solução dos problemas de gerenciamento de volumes de
dados. Existem várias técnicas para que se alcance a estabilidade horizontal,
uma muito conhecida é o Sharding, que consiste em dividir os dados em
múltiplas tabelas a serem armazenadas ao longo de diversos nós de uma rede.
 Ausência de esquema ou esquema flexível: Uma das principais
características dos bancos de dados NoSQL é ausência completa ou quase total
do esquema que define a estrutura dos dados modelados. Devido a essa
ausência há uma fácil aplicação da escalabilidade e também um aumento na
disponibilidade. Mas também devido a essa ausência, não há garantia da
integridade dos dados.
 Suporte a Replicação: Os banco de dados NoSQL permitem a replicação de
uma forma nativa o que provém uma escalabilidade maior e também uma
diminuição do tempo gasto para a recuperação de informações. Os bancos




NoSQL conseguem implementar as duas formas de replicação, a Master-Slave
(Mestre-Escravo) e a Master-to-Master (Mestre-Mestre).
API Simples para fácil acesso dos dados: Como o intuito do NoSQL é fazer
com que o acesso aos dados seja feito de uma forma rápida, oferecendo alta
disponibilidade e escalabilidade, ele está totalmente focado para que à
recuperação dos dados seja feita de forma eficiente, ignorando em como os
dados serão armazenados. Para que esse objetivo seja alcançado APIs que
facilitam o acesso às informações são desenvolvidos, permitindo assim que
qualquer aplicação possa ter acesso aos dados do banco de forma rápida e
eficiente.
Nem sempre Consistente: Outra característica importante dos bancos de
dados NoSQL é que eles nem sempre conseguem se manter consistentes. Esta
característica tem como princípio o teorema CAP, que diz que, em um certo
momento, só há garantia de duas das três propriedades estejam ativas.

2.3
TÉCNICAS PARA IMPLEMENTAÇÃO
Existem algumas técnicas muito importantes para que a implementação de todas as
funcionalidades do NoSQL sejam eficientes. Alguns exemplos são:
 Map/Reduce: O Map/Reduce dá suporte ao manuseio de grandes volumes de
dados distribuídos ao longo dos nós de uma rede. Essa técnica é dividida em
duas fases, a primeira é fase de Map onde os problemas são quebrados e
divididos em subproblemas, depois são distribuídos entre os nós da rede. A
segunda é fase de Reduce, nela os subproblemas são resolvidos em cada nó
filho e o resultado é repassado ao pai, que, sendo ele também ele filho,
repassaria ao seu pai, e assim por diante até chegar ao nó raiz do problema.
 Consistent Hashing: O Consistent Hashing tem a função de suportar o
mecanismos de armazenamento e recuperação em bancos de dados
distribuídos.
 Multiversion Concurrency control (MVCC): O MVCC é um mecanismo
que dá suporte a transações paralelas em um banco de dados. Por não utilizar
bloqueios ele permite que operações de leitura e escrita sejam efetuadas
simultaneamente, diferente do esquema clássico de gerenciamento de
transações.
 Vector clocks: Como há a possibilidade de muitas operações estarem sendo
executadas simultaneamente sobre o mesmo item de dado distribuído é
importante determinar qual versão do dado distribuído é a mais atual. Isso é
possível graças ao Vector Clocks.
2.4
PRINCIPAIS TIPOS
Existem vários tipos de modelos de dados NoSQL. Falaremos de 4 tipos principais
desse modelos. São eles: Chave-Valor (Key-Value), Orientado a Documentos,
Orientado a Colunas e Orientado a Grafos.
2.5
BANCO DE DADOS CHAVE-VALOR (key-value)
Este modelo é bem simples e nos permite a visualização do banco de dados como uma
grande tabela hash. Da maneira mais simples possível, todo o banco de dados é
composto por um conjunto de chaves, chaves que estão associadas a um único valor.
Na figura 1.0 temos um exemplo de como é armazenado um dado em um banco de
dados chave-valor, nessa figura podemos ver os campos e suas instancias. A chave
representa o campo, como por exemplo Nome, Idade, Sexo e Fone e o Valor
representa a própria instancia para o campo que corresponde.

Por este modelo ser de fácil implementação, ele permite que os dados sejam
acessados muito rapidamente pela chave, isso principalmente em sistemas que
possuem alta escalabilidade o que também contribui para no aumento da
disponibilidade de acesso aos dados.
Em relação a manipulação dos dados, as operações são bem simples como
por exemplo o get( ) (Usado para retorna o valor) e o set( ) (Usado para Capturar o
valor). Uma das desvantagens desse modelo é que ele não permite a recuperação de
objetos por meio de consultas mais complexas.
Um bom exemplo de Banco de dados que adota esse modelo é o Dynamo,
desenvolvido pela Amazon, posteriormente foi utilizado como base para o
desenvolvimento do Cassandra (banco de dados desenvolvido para o Facebook). Com
o Dynamo podemos realizar particionamento, replicação e versionamento dos dados.
Além do Dynamo, temos outros banco de dados que seguem o modelo chave-valor
são eles: Redis, Riak e o GenieDB.
2.6
BANCO DE DADOS ORIENTADO A COLUNAS
O modelo orientado a colunas é um pouco mais complexo que o modelo chave-valor.
Neste tipo de modelo os dados são indexados por uma tripla (linha, coluna e
timestramp), onde as linhas e as colunas são identificadas por chaves e o timestramp
é o que permite identificar as diferentes versões de um mesmo dado. Em um banco
de dados orientado a colunas as operações de leitura e escrita são atômicas, ou seja,
todos os valores associados a uma linha são considerados na execução da operação de
leitura ou escrita. Um outro conceito importante sobre esse modelo é o de família de
colunas (column family), é usado com o objetivo de agrupar colunas que armazenam
o mesmo tipo de dados.
Este modelo de surgiu com o BigTable da Google. Suas principais
características são: Permitir particionamento, oferecer forte consistência e não
garantir alta disponibilidade.
2.7
BANCO DE DADOS ORIENTADO A DOCUMENTOS
Este modelo armazena coleções de documentos. Um documento no geral, é um objeto
com um código único e um conjunto de campos, que podem ser strings, listas ou
documentos aninhados. A estrutura desses campos se parecem com a estrutura dos
campos do modelo chave-valor. No modelo de chave-valor, uma única tabela hash é
criada para todo o banco de dados. Já no modelo orientado a documentos, temos um
conjunto de documentos e em cada documento temos um conjunto de chaves
(campos) cada uma com sua chave (key). Um outra característica importantes sobre
este modelo é que ele não depende de um esquema rígido, ou seja, não há exigência
de uma estrutura fixa. Desse jeito é possível ocorrer uma atualização na estrutura do
documentos sem causar problema algum ao banco de dados. Por exemplo a adição de
novos campos ao documento não causará nenhum problema ao banco. Essa facilidade
e flexibilidade em atualizar a estrutura dos documentos é uma das grandes e principais
vantagens do modelo orientado a documentos.
Dentre os bancos de dados que utilizam esse modelo podemos citar o
CouchDB e o MongoDB.
2.8
BANCO DE DADOS ORIENTADO A GRAFOS
O modelo orientado a grafos possui três componentes básicos: os nós (são os vértices
do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós
e relacionamentos. Neste modelo, o banco de dados pode ser comparado com um
multigrafo rotulado e direcionado, onde cada nó pode ser conectado por mais de uma
aresta.
A utilização de banco de dados orientado a grafos é vantajosa quando
consultas complexas são exigidas pelo usuário, se comparado com o modelo
conceitual onde essas
consultas teriam uma
implementação enorme e
perca de desempenho, nos
bancos de dados orientados
a grafos esse tipo de
consulta teria uma ganho
de performance o que
permitiria um melhor
desempenho
das
aplicações. Exemplos de
banco de dados baseados
em grafos são: Neo4j,
AllegroGraph e Virtuoso.
Figura 1.1 – Exemplo de BD
Orientado a Grafos
3.1
BASE VS ACID
Hoje a internet com seus sites, blogs, redes sociais, etc criam uma enorme quantidade
de dados, dados que precisam ser processados, analisados e entregues aos usuários
que os requisitam. As empresas, organizações ou indivíduos que oferecem aplicações
ou serviços nesta área tem que determinar suas necessidades individuais em relação
ao desempenho, confiabilidade, disponibilidade, consistência e durabilidade. Para a
maioria das aplicações web, especialmente as de grande escala, a disponibilidade e
tolerância a partição são mais importantes do que a consistência. Estas aplicações têm
que ser confiáveis, o que implica em disponibilidade e redundância. Estas
propriedades são difíceis de se alcançar usando as propriedades ACID, assim se opta
por usar as propriedades de BASE.
A BASE perde as propriedades de consistência e isolamento em favor de
ganhar “disponibilidade e ganho de performance”. Para entendermos melhor,
explicaremos as propriedades ACID e em seguida as de BASE:
 A – Atomicidade: A propriedade de atomicidade garante que as transações
sejam atômicas (indivisíveis). A transação será executada totalmente ou não
será executada.
 C – Consistência: A propriedade de consistência garante que o banco de
dados passará de uma forma consistente para outra forma consistente.
 I – Isolamento: A propriedade de isolamento garante que a transação não
será interferida por nenhuma outra transação concorrente.
 D – Durabilidade: A propriedade de durabilidade garante que o que foi
salvo, não será mais perdido.
Como já dito anteriormente, hoje as aplicações web movimentam uma grande
quantidade de dados, e assim elas não conseguem manter todas as propriedades ACID
e um bom desempenho das aplicações ao mesmo tempo, desse jeito as empresas
optaram por perder uma das propriedades para suprir suas necessidades mais
importantes. E então surge as propriedades de BASE que são:
 BA – (Basically Available) Basicamente Disponivel – Prioridade na
disponibilidade dos dados.
 S - (Soft-State) Estado leve – O sistem não precisa ser consistente o tempo
todo.
 E – (Eventually Consistent) Eventualmente Consistente - Consistente em
momento indeterminado.
Pode-se resumir as propriedades de Base da seguinte forma: Uma aplicação funciona
basicamente todo o tempo (Basicamente Disponível), não tem de ser consistente todo
o tempo (Eventualmente Consistente).
A seguir temos uma tabela que nôs mostra as principais diferenças entre as
propriedades ACID e BASE:
ACID
Consistência forte
Isolamento
Concentra-se em "commit"
Transações aninhadas
Disponibilidade
Conservador (pessimista)
Evolução difícil (por exemplo, esquema)

BASE
Fraca consistência
Foco em Disponibilidade
Melhor esforço
Respostas aproximadas
Mais simples e mais rápido
Agressivo (otimista)
Evolução mais fácil

Se analisarmos bem a tabela, poderemos ver que as propriedades de BASE se focam mais
em Disponibilidade e Desempenho, que são as necessidades mais básicas de uma
aplicação web, disponibilizar os dados que o usuário requisitar e fazer isso de uma forma
rápida e simples.
4.1
TEOREMA CAP
Existem muitas motivos para se usar os bancos de dados NoSQL, como por exemplo usar
um modelo mais adequado para os seus dados ou facilitar alterações no esquema, ou até
melhorar o desempenho e simplificar a replicação para se alcançar a escalabilidade linear.
Como não conseguimos usar todos esses benefícios sem um custo, vamos
perder alguma funcionalidade para se ganhar outra. Primeiramente explicaremos cada um
dos 3 pontos do Teorema CAP, que são a Consistência, Disponibilidade e a Tolerância a
falhas.


Consistency (Consistência): Consistência é a característica que descreve como e
se o estado de um sistema fica consistente após uma operação. Num sistema
distribuído de dados, isto, normalmente significa que uma vez escrito um registo,
este fica disponível para ser utilizado imediatamente, ou seja cada cliente tem
sempre a mesma visão dos dados.
 Availability (Disponibilidade): Refere-se à concepção e implementação de um
sistema de modo que seja assegurado que este permanece ativo durante um
determinado período de tempo. Neste contexto, significa que um sistema é
tolerante a falhas de software/hardware e normalmente também permanece
disponível durante a atualização de software e hardware. Um bom exemplo seria
falar que todos os clientes de uma empresa que acessam um a aplicação web,
podem sempre ler e atualizar dados na aplicação.
 Partition Tolerance (Tolerância ao Particionamento): Refere-se a capacidade
de um sistema continuar operando mesmo depois uma falha na rede. Ou seja
significa garantir que operações serão completadas, mesmo que componentes
individuais não estejam disponíveis. Tolerância ao Particionamento é a
capacidade de um sistema se manter operante mesmo em casos onde ocorra uma
interrupção parcial de alguns componentes.
Explicado os três pontos principais que um sistema web deverá ter, o teorema CAP
explica que em sistema distribuído é preciso escolher entre duas dessas propriedade,
nunca conseguindo usar as três ao mesmo tempo. Assim é preciso escolher entre
Consistência forte, alta disponibilidade e tolerância ao particionamento. Sendo que entre
as três propriedades, somente duas podem ser garantidas ao mesmo tempo. Seguindo essa
ideia podemos ter três tipos de sistemas:
Sistemas CA: Os sistemas com consistência forte e alta disponibilidade (CA) (alta
disponibilidade de um nó apenas) não sabem lidar com a possível falha de uma partição.
Caso ocorra, sistema inteiro pode ficar indisponível até o membro do cluster voltar.
Exemplos disso são algumas configurações clássicas de bancos relacionais.
Sistemas CP: Para sistemas que precisam da consistência forte e tolerância a
particionamento é necessário abrir a mão da disponibilidade (um pouco). Pode acontecer,
caso haja particionamento e o sistema não entre em consenso, que uma escrita seja
rejeitada. Claro que os sistemas tentam evitar isso ao máximo, tanto que não costuma
existir, por exemplo, uma transação distribuída e sim um protocolo de consensos para
garantir a consistência forte. Exemplos desses sistemas CP são BigTable, HBase ou
MongoDB entre vários outros.
Sistemas AP: Por outro lado existem sistemas que jamais podem ficar offline,
portanto não desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo
com um tolerância a particionamento é preciso prejudicar a consistência. A ideia aqui é
que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum
momento depois (read-consistency). Então pode ter uma janela de inconsistência.
Exemplos aqui são Amazon Dynamo, Cassandra ou Riak.
5.1 PARA QUE É INDICADO O NOSQL ?
Como dito na introdução o modelo de dados NoSQL é indicado para aplicações que irão
trabalhar com enormes quantidades de dados, onde o modelo de dados relacional não
atende mais as expectativas dessas aplicações. Uma das principais vantagens no uso de
banco de dados não-relacionais está no fato de sua utilização horizontal, ou seja, a
distribuição de dados através de bancos disseminados em diferentes servidores, ao
contrário do padrão dos bancos mais utilizados e relacionais. Por isso os bancos de dados
NoSQL são indicados para grandes cargas de dados, exigências de velocidade na consulta
e escrita em grandes volumes de dados.
6.1 PRINCIPAIS PRODUTOS NO MERCADO
Os principais bando de dados não-relacionais encontrados hoje são:
 MongoDB
 CouchDB
 Cassandra
 Project Valdemort (by Linkedin)
 Redis (by Google)
 HBase (by Apache)
 Dynamo (by Amazon)
 dentre muitos outros…
7.1 PRINCIPAIS UTILIZADORES DO NOSQL
Os principais utilizadores do NoSQL são é claro as empresas que processam uma enorme
quantidade de dados e esses dados devem estar acessíveis de forma rápida, exemplos de
empresas que adotaram o modelo NoSQL são:
 Google ..................................................................... Banco de dados Bigtable.
 Amazon.................................................................... Banco de dados Dynamo.
 Yahoo ...................................................................... Banco de dados Hadoop.
 Facebook .................................................................. Banco de dados Cassandra.
 Digg ......................................................................... Banco de dados Cassandra.
 Twitter ..................................................................... Banco de dados Cassandra.
 IBM .......................................................................... Banco de dados Cassandra.
 Netflix ...................................................................... Banco de dados Cassandra.
 LinkedIn .................................................................. Banco de dados Voldemort.
 Engine Yard ............................................................. Banco de dados MongoDB.
8.1 INSTALAÇÃO DO BANCO DE DADOS MYSQL NDB CLUSTER
Instalaremos uma versão do MySQL Cluster simples em um servidor Linux. Então siga
os passos corretamente:
1. Download
Baixar o MySQL Cluster através do site: http://dev.mysql.com/downloads/cluster/
certifique-se de selecionar a plataforma correta, neste caso ‘Debian Linux’, e em seguida
‘Debian Linux versão 6.0 (x86, 64-bit), DEB’.
2. Instalação
Localize o arquivo que você baixou, extraia e em seguida crie um link para ele:
[user1@ws2 ~] $ tar xvf Downloads/4839919.mysql-cluster-advanced7.2.4-linux2.6-x86_64.tar.gz
[user1@ws2 ~] $ ln-s mysql-cluster-advanced-7.2.4-Linux2.6-x86_64
mysqlc
3. Configuração
Crie pastas para armazenar os arquivos de configuração e os arquivos de dados:
[user1@ws2 ~] $ mkdir my_cluster my_cluster / ndb_data my_cluster
/ mysqld_data my_cluster / conf
Dentro da pasta ‘conf’ crie 2 arquivos:
My.cnf:
[Mysqld]
ndbcluster
datadir = / home/user1/my_cluster/mysqld_data
basedir = / home/user1/mysqlc
port = 5000
config.ini:
[ndb_mgmd]
hostname = localhost
datadir = / home/user1/my_cluster/ndb_data
NodeId = 1
[ndbd default]
noofreplicas = 2
datadir = / home/user1/my_cluster/ndb_data
[ndbd]
hostname = localhost
NodeId = 3
[ndbd]
hostname = localhost
NodeId = 4
[mysqld]
NodeId = 50
Assim como qualquer outro MySQL, o processo requer um banco de dados ‘mysql’ para
ser criado e preenchido com os dados essenciais para o sistema.
[user1@ws2] $ cd mysqlc
[user1@ws2 mysqlc] $ scripts/mysql_install_db --no-defaults -datadir =$HOME/my_cluster/mysqld_data/
4. Execução
Os processos devem ser iniciados na ordem de nó de gerenciamento, nó de dados e por
último o MySQL:
[userl@ws2 mysqlc]$ cd ../my_cluster/
[userl@ws2
my_cluster]$
$HOME/mysqlc/bin/ndb_mgmd
–f
conf/config.ini –initial –
Configdir=$HOME/my_cluster/conf/
[userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndbd –c localhost:1186
[userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndbd –c localhost:1186
Verifique o status do cluster e espere os nós concluírem para que você possa iniciar o
servidor MySQL:
[userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndb_mgm –e show
Connected to Management Server at: localhost: 1186
Cluster Configuration
------------------------[ndbd (NDB)]
2 node(s)
id=3
@127.0.0.1
(mysql-5.5.19 ndb-7.2.4,
Nodegroup: 0, Master)
id=4
@127.0.0.1
(mysql-5.5.19 ndb-7.2.4,
Nodegroup: 0)
[ndb_mgmd(MGM) ] 1 node(s)
id=1
@127.0.0.1
(mysql-5.5.19 ndb-7.2.4)
[mysqld(API)]
1 node(s)
Id=50
(not connected, accepting connect from any
host)
[userl@ws2
my_cluster]$
defaults-file=conf/my.cnf &

$HOME/mysqlc/bin/mysqld

–

5. Teste
Conecte-se ao servidor MySQL e crie uma tabela.
[userl@ws2 my_cluster]$ $HOME/mysqlc/bin/mysql –h 127.0.0.1 –P
5000 –u root
mysql> create database clusterdb;
mysql> use clusterdb;
mysql> create table simples (
id int not null primary key
)engine = ndb;
mysql> insert into simples values (1),(2),(3),(4);
mysql> select * from simples;
+----+
| id |
+----+
| 3 |
| 1 |
| 2 |
| 4 |
+----+

9.1
CONCLUSÃO
Devemos ressaltar quais são os focos principais do NoSQL que são a performance, ou
seja o desempenho das aplicações mediante a uma enorme quantidade de dados a ser
processados. E a escalabilidade horizontal , que é capacidade de se aumentar a capacidade
de processamento dos dados adicionado mais servidores a rede. Também devemos
ressaltar a simplicidade e facilidade na implantação e uso dos bancos de dados NoSQL,
bem como seus ótimos resultados.
Mas um ponto comum entre as empresas que têm adotado essa tecnologia, são
alguns problemas enfrentados pelas mesmas quando fazem uso de uma grande quantidade
de dados, e estes dados precisam ser compartilhados com extrema rapidez. Para que esse
problema seja resolvido, é necessário que as aplicações sejam escaláveis e seus dados
tenham uma alta disponibilidade.
Temos que deixar claro que a solução NoSQL não veio substituir o modelo
relacional, mas sim tentar suprir as novas necessidades das aplicações tem, fazendo com
que possam gerenciar os seus dados de uma forma mais eficiente. Permitindo que as
aplicações tenham vantagens como: Alta disponibilidade dos dados, escalabilidade,
esquema flexível, alto desempenho e gerenciamento de dados semi-estruturados. Em
troca de tudo isso vale lembrar que nem sempre vai ser possível garantir que os dados
estejam consistentes, que haja um controle na concorrência, dentre outras características
dos banco de dados tradicionais.
10.1 REFERÊNCIAS BIBLIOGRÁFICAS


NOSQL :
 http://blog.hostdime.com.br/materias/tecnologia/mysql-postgresql-ms-sql-servernao-e-a-vez-do-nosql/




NoSQl no Desenvolvimento de Aplicações WEB colaborativas – Bernadette Farias
Lóscio (bfl@cin.ufpe.br), Hélio Rodrigues de Oliveira (fro@cin.ufpe.br), Jonas César
de Sousa Pontes (jcs@cin.ufpe.br).



http://imasters.com.br/artigo/21781/banco-de-dados/escolhendo--a-ferramentacerta-para-o-banco-de-dados-nosql/






http://www.slideshare.net/mdediana/no-sqlvantagensdesvantagensecompromissos

http://www.devmedia.com.br/introducao-aos-bancos-de-dados-nosql/26044
http://ccsl.ime.usp.br/wiki/images/2/20/NoSQL_Vantagens_Desvantagens_e_Com
promissos.pdf

BASE vs ACID
 http://ssdi.di.fct.unl.pt/bd/docs/slides/aula15.pdf
 http://blog.lucasrenan.com/propriedades-acid/



TEOREMA CAP
 http://blog.caelum.com.br/nosql-do-teorema-cap-para-paccl/
 http://blog.nahurst.com/visual-guide-to-nosql-systems
 http://elemarjr.net/2011/08/11/cap-theorem-e-alternativa-para-o-acid/
 MySQL NDB Cluster:
 http://www.clusterdb.com/mysql-cluster/mysql-cluster-manager-1-1-2-creating-acluster-is-now-trivial/



http://dev.mysql.com/downloads/mirror.php?id=413395

Mais conteúdo relacionado

Mais procurados

Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)
Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)
Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)Cathrine Wilhelmsen
 
You Need a Data Catalog. Do You Know Why?
You Need a Data Catalog. Do You Know Why?You Need a Data Catalog. Do You Know Why?
You Need a Data Catalog. Do You Know Why?Precisely
 
Power data mdm
Power data  mdmPower data  mdm
Power data mdmPowerData
 
Banco de Dados II Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)
Banco de Dados II  Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)Banco de Dados II  Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)
Banco de Dados II Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)Leinylson Fontinele
 
Banco de Dados Distribuídos - MySql
Banco de Dados Distribuídos - MySqlBanco de Dados Distribuídos - MySql
Banco de Dados Distribuídos - MySqlAdail Viana Neto
 
(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling
(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling
(OTW13) Agile Data Warehousing: Introduction to Data Vault ModelingKent Graziano
 
Arquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dadosArquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dadosdiogocbj
 
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)Leinylson Fontinele
 
No sql Orientado a documento
No sql Orientado a documentoNo sql Orientado a documento
No sql Orientado a documentoAlex Martins
 
DAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data ModelerDAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data ModelerDATAVERSITY
 
Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...
Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...
Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...Leinylson Fontinele
 
Introduction of ssis
Introduction of ssisIntroduction of ssis
Introduction of ssisdeepakk073
 
Sql o NoSql en Informática Médica
Sql o NoSql en Informática MédicaSql o NoSql en Informática Médica
Sql o NoSql en Informática MédicaLiz Armenteros
 
Architect’s Open-Source Guide for a Data Mesh Architecture
Architect’s Open-Source Guide for a Data Mesh ArchitectureArchitect’s Open-Source Guide for a Data Mesh Architecture
Architect’s Open-Source Guide for a Data Mesh ArchitectureDatabricks
 
Árvore B estruturas de dados e técnicas de programação
Árvore B estruturas de dados e técnicas de programaçãoÁrvore B estruturas de dados e técnicas de programação
Árvore B estruturas de dados e técnicas de programaçãoEverson Wolf
 

Mais procurados (20)

Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)
Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)
Pipelines and Packages: Introduction to Azure Data Factory (DATA:Scotland 2019)
 
You Need a Data Catalog. Do You Know Why?
You Need a Data Catalog. Do You Know Why?You Need a Data Catalog. Do You Know Why?
You Need a Data Catalog. Do You Know Why?
 
Power data mdm
Power data  mdmPower data  mdm
Power data mdm
 
Banco de Dados II Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)
Banco de Dados II  Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)Banco de Dados II  Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)
Banco de Dados II Aula 02 - Modelagem de Dados (Definição, Modelo conceitual)
 
Banco de Dados Distribuídos - MySql
Banco de Dados Distribuídos - MySqlBanco de Dados Distribuídos - MySql
Banco de Dados Distribuídos - MySql
 
NoSQL et Big Data
NoSQL et Big DataNoSQL et Big Data
NoSQL et Big Data
 
(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling
(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling
(OTW13) Agile Data Warehousing: Introduction to Data Vault Modeling
 
Arquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dadosArquitetura e sgbd de um banco de dados
Arquitetura e sgbd de um banco de dados
 
Selecting best NoSQL
Selecting best NoSQL Selecting best NoSQL
Selecting best NoSQL
 
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
Banco de Dados II Aula 04 - MODELAGEM DE DADOS (Generalização e Especialização)
 
Introdução ao Hive
Introdução ao HiveIntrodução ao Hive
Introdução ao Hive
 
Aula 08 - árvores
Aula 08 - árvoresAula 08 - árvores
Aula 08 - árvores
 
No sql Orientado a documento
No sql Orientado a documentoNo sql Orientado a documento
No sql Orientado a documento
 
DAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data ModelerDAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
DAS Slides: Data Architect vs. Data Engineer vs. Data Modeler
 
Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...
Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...
Introdução à Computação - Aula Prática 3 - Banco de Dados (Conversão do model...
 
re:dash is awesome
re:dash is awesomere:dash is awesome
re:dash is awesome
 
Introduction of ssis
Introduction of ssisIntroduction of ssis
Introduction of ssis
 
Sql o NoSql en Informática Médica
Sql o NoSql en Informática MédicaSql o NoSql en Informática Médica
Sql o NoSql en Informática Médica
 
Architect’s Open-Source Guide for a Data Mesh Architecture
Architect’s Open-Source Guide for a Data Mesh ArchitectureArchitect’s Open-Source Guide for a Data Mesh Architecture
Architect’s Open-Source Guide for a Data Mesh Architecture
 
Árvore B estruturas de dados e técnicas de programação
Árvore B estruturas de dados e técnicas de programaçãoÁrvore B estruturas de dados e técnicas de programação
Árvore B estruturas de dados e técnicas de programação
 

Semelhante a Sistemas NoSQL, surgimento, características e exemplos

NoSQL Familia de Colunas Monografia
NoSQL Familia de Colunas MonografiaNoSQL Familia de Colunas Monografia
NoSQL Familia de Colunas MonografiaAugusto Giles
 
No sql no desenvolvimento de aplicações web colaborativas
No sql no desenvolvimento de aplicações web colaborativasNo sql no desenvolvimento de aplicações web colaborativas
No sql no desenvolvimento de aplicações web colaborativasJoão Gabriel Lima
 
NoSQL x SQL: Bancos de Dados em Nuvens Computacionais
NoSQL x SQL: Bancos de Dados em Nuvens ComputacionaisNoSQL x SQL: Bancos de Dados em Nuvens Computacionais
NoSQL x SQL: Bancos de Dados em Nuvens ComputacionaisCarlo Pires
 
Cobo, Cristiane Brandão. Especialização Banco de Dados
Cobo, Cristiane Brandão. Especialização Banco de DadosCobo, Cristiane Brandão. Especialização Banco de Dados
Cobo, Cristiane Brandão. Especialização Banco de Dadoscris.finholdt
 
Cluster ha com banco de dados
Cluster ha com banco de dadosCluster ha com banco de dados
Cluster ha com banco de dadosMarcio Jonnes
 
Desenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQL
Desenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQLDesenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQL
Desenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQLOtávio Santana
 
MySQL 5.6, o que há de novidade?
MySQL 5.6, o que há de novidade?MySQL 5.6, o que há de novidade?
MySQL 5.6, o que há de novidade?MySQL Brasil
 
Apresentação Modelo de Gestão de dados para sistemas Colaborativos
Apresentação Modelo de Gestão de dados para sistemas ColaborativosApresentação Modelo de Gestão de dados para sistemas Colaborativos
Apresentação Modelo de Gestão de dados para sistemas ColaborativosMozart Dornelles Claret
 

Semelhante a Sistemas NoSQL, surgimento, características e exemplos (20)

NoSQL Familia de Colunas Monografia
NoSQL Familia de Colunas MonografiaNoSQL Familia de Colunas Monografia
NoSQL Familia de Colunas Monografia
 
Material Seminário NoSQL
Material Seminário NoSQLMaterial Seminário NoSQL
Material Seminário NoSQL
 
Artigo Nosql
Artigo NosqlArtigo Nosql
Artigo Nosql
 
xxx no sequel
xxx no sequelxxx no sequel
xxx no sequel
 
No sql no desenvolvimento de aplicações web colaborativas
No sql no desenvolvimento de aplicações web colaborativasNo sql no desenvolvimento de aplicações web colaborativas
No sql no desenvolvimento de aplicações web colaborativas
 
NoSQL x SQL: Bancos de Dados em Nuvens Computacionais
NoSQL x SQL: Bancos de Dados em Nuvens ComputacionaisNoSQL x SQL: Bancos de Dados em Nuvens Computacionais
NoSQL x SQL: Bancos de Dados em Nuvens Computacionais
 
NoSQL
NoSQLNoSQL
NoSQL
 
Artigo de banco de dados
Artigo  de banco de dadosArtigo  de banco de dados
Artigo de banco de dados
 
Cobo, Cristiane Brandão. Especialização Banco de Dados
Cobo, Cristiane Brandão. Especialização Banco de DadosCobo, Cristiane Brandão. Especialização Banco de Dados
Cobo, Cristiane Brandão. Especialização Banco de Dados
 
Cluster ha com banco de dados
Cluster ha com banco de dadosCluster ha com banco de dados
Cluster ha com banco de dados
 
C # banco de dados
C # banco de dadosC # banco de dados
C # banco de dados
 
Pesquisa sobre no sql
Pesquisa sobre no sqlPesquisa sobre no sql
Pesquisa sobre no sql
 
Desenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQL
Desenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQLDesenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQL
Desenvolvendo com NOSQL ­ Cassandra em Java: Parte 1 ­ Conceito NOSQL
 
MySQL 5.6, o que há de novidade?
MySQL 5.6, o que há de novidade?MySQL 5.6, o que há de novidade?
MySQL 5.6, o que há de novidade?
 
Artigo couchdb
Artigo couchdbArtigo couchdb
Artigo couchdb
 
Introdução ao NoSQL
Introdução ao NoSQLIntrodução ao NoSQL
Introdução ao NoSQL
 
Nosql
NosqlNosql
Nosql
 
My sql apresentação
My sql apresentaçãoMy sql apresentação
My sql apresentação
 
Apresentação Modelo de Gestão de dados para sistemas Colaborativos
Apresentação Modelo de Gestão de dados para sistemas ColaborativosApresentação Modelo de Gestão de dados para sistemas Colaborativos
Apresentação Modelo de Gestão de dados para sistemas Colaborativos
 
Tcc versao final-15-12
Tcc versao final-15-12Tcc versao final-15-12
Tcc versao final-15-12
 

Mais de Aricelio Souza

Testes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de CódigoTestes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de CódigoAricelio Souza
 
Metodologia Ágil Scrum
Metodologia Ágil ScrumMetodologia Ágil Scrum
Metodologia Ágil ScrumAricelio Souza
 
Padrões Arquiteturais - MVC, MVP e MVVM
Padrões Arquiteturais - MVC, MVP e MVVMPadrões Arquiteturais - MVC, MVP e MVVM
Padrões Arquiteturais - MVC, MVP e MVVMAricelio Souza
 
Padrões de projeto - Martin Fowler - P of EAA
Padrões de projeto - Martin Fowler - P of EAAPadrões de projeto - Martin Fowler - P of EAA
Padrões de projeto - Martin Fowler - P of EAAAricelio Souza
 
Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...
Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...
Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...Aricelio Souza
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de SoftwareAricelio Souza
 
Ataques DOS, DDOS e Scamming
Ataques DOS, DDOS e ScammingAtaques DOS, DDOS e Scamming
Ataques DOS, DDOS e ScammingAricelio Souza
 
Documentação Ataques DOS, DDOS e Scamming
Documentação Ataques DOS, DDOS e ScammingDocumentação Ataques DOS, DDOS e Scamming
Documentação Ataques DOS, DDOS e ScammingAricelio Souza
 

Mais de Aricelio Souza (9)

Testes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de CódigoTestes de Caixa Branca e Métricas de Código
Testes de Caixa Branca e Métricas de Código
 
Metodologia Ágil Scrum
Metodologia Ágil ScrumMetodologia Ágil Scrum
Metodologia Ágil Scrum
 
Padrões Arquiteturais - MVC, MVP e MVVM
Padrões Arquiteturais - MVC, MVP e MVVMPadrões Arquiteturais - MVC, MVP e MVVM
Padrões Arquiteturais - MVC, MVP e MVVM
 
Tipos de Servidores
Tipos de ServidoresTipos de Servidores
Tipos de Servidores
 
Padrões de projeto - Martin Fowler - P of EAA
Padrões de projeto - Martin Fowler - P of EAAPadrões de projeto - Martin Fowler - P of EAA
Padrões de projeto - Martin Fowler - P of EAA
 
Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...
Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...
Comparativo tecnico entre tecnologias de banco de dados: Relacional, NoSQL, N...
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Ataques DOS, DDOS e Scamming
Ataques DOS, DDOS e ScammingAtaques DOS, DDOS e Scamming
Ataques DOS, DDOS e Scamming
 
Documentação Ataques DOS, DDOS e Scamming
Documentação Ataques DOS, DDOS e ScammingDocumentação Ataques DOS, DDOS e Scamming
Documentação Ataques DOS, DDOS e Scamming
 

Último

ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx2m Assessoria
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx2m Assessoria
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx2m Assessoria
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPaulo Pagliusi, PhD, CISM
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASMarcio Venturelli
 

Último (8)

ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docxATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
ATIVIDADE 1 - GESTÃO DE PESSOAS E DESENVOLVIMENTO DE EQUIPES - 52_2024.docx
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 
Entrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo PagliusiEntrevistas, artigos, livros & citações de Paulo Pagliusi
Entrevistas, artigos, livros & citações de Paulo Pagliusi
 
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docxATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
ATIVIDADE 1 - CÁLCULO DIFERENCIAL E INTEGRAL II - 52_2024.docx
 
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo PagliusiPalestras sobre Cibersegurança em Eventos - Paulo Pagliusi
Palestras sobre Cibersegurança em Eventos - Paulo Pagliusi
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINASCOI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
COI CENTRO DE OPERAÇÕES INDUSTRIAIS NAS USINAS
 

Sistemas NoSQL, surgimento, características e exemplos

  • 1. DISCIPLINA BANCO DE DADOS II PROFESSOR: PETRONIO CANDIDO NOSQL BASE X ACID TEOREMA CAP ARICELIO DE SOUZA FERNANDES 3º PERIODO JANUÁRIA JUNHO DE 2013
  • 2. SUMÁRIO 1.1 INTRODUÇÃO ............................................................................................. 02 2.1 NOSQL .......................................................................................................... 02 2.2 PRINCIPAIS CARACTERÍSTICAS ............................................................ 03 2.3 TÉCNICA PARA IMPLEMENTAÇÃO....................................................... 04 2.4 PRINCIPAIS TIPOS ..................................................................................... 05 2.5 BANCO DE DADOS CHAVE-VALOR ...................................................... 05 2.6 BANCO DE DADOS ORIENTADO A COLUNAS .................................... 05 2.7 BANCO DE DADOS ORIENTADO A DOCUMENTOS ........................... 06 2.8 BANCO DE DADOS ORIENTADO A GRAFOS ....................................... 06 3.1 BASE X ACID .............................................................................................. 07 4.1 TEOREMA CAP ........................................................................................... 08 5.1 PARA QUE É INDICADO O NOSQL? ....................................................... 10 6.1 PRINCIAPAIS PRODUTOS NO MERCADO............................................. 10 7.1 PRINCIPAIS UTILIZADORES DO NOSQL .............................................. 10 8.1 INSTALAÇÃO DO BANCO DE DADOS MYSQL NDB CLUSTER ....... 10 9.1 CONCLUSÃO ............................................................................................... 13 10.1 REFERENCIAS BIBILOGRÁFICAS .......................................................... 14
  • 3. 1.1 INTRODUÇÃO Bancos de dados relacionais hoje são a tecnologia predominante para armazenar dados estruturados, tanto em aplicações dentro da web como fora dela. A partir de 1970 o armazenamento de dados baseado em cálculo relacional foi amplamente adotado e muitos pensaram ser a única alternativa para o armazenamento de dados acessível por vários clientes de uma forma consistente. Nos últimos anos, o pensamento sobre como armazenar grandes quantidades de dados tem sido bastante questionado, e isso levou ao surgimento de uma grande variedade de alternativas. O movimento, bem como as novas formas de armazenamento de dados foram agrupados sob o termo de NoSQL (Not Only SQL), bancos de dados não-relacionais. O termo NoSQL foi usado pela primeira vez em 1998 para um banco de dados relacional que omitiu o uso de SQL. O termo foi usado novamente em 2009 em conferências de defensores de banco de dados não-relacionais. A revista americana Computer World afirmou em um de seus artigos que os bancos de dados não-relacionais vieram para acabar com a tirania dos lentos e caros bancos de dados relacionais, com formas mais eficientes e mais baratas de gerenciamento de banco de dados. A exemplo temos o Cassandra - Originalmente foi desenvolvido para um recurso do Facebook, que de acordo com o engenheiro Avinash Lakshman tem o poder de escrever 2500 vezes mais rápido em um grande banco de dados de 50 Gb do que o MySQL. Uma das principais vantagens no uso de bancos de dados não-relacionais está no fato de sua utilização horizontal, ou seja, a distribuição de dados através de bancos disseminados em diferentes servidores, ao contrário do padrão dos bancos mais utilizados e relacionais (MySQL, MS SQL Server, PostgreSQL, etc.), em que é necessário promover o seu crescimento verticalizado. 2.1 NOSQL NoSQL (Not Only SQL) significa “Não Apenas SQL”, esse termo referencia a Sistemas de Gerenciamento de Banco de Dados (SGBDs) que não adotam o modelo relacional (daí o nome Bancos de Dados Não-Relacionais) e são mais flexíveis quanto ás propriedades ACID. Esta flexibilidade é necessária devido aos requisitos de alta escalabilidade para o gerenciamento das grandes quantidades de dados e a alta disponibilidades dos mesmos. Como já abordado, o termo NoSQL engloba todos os tipos de bancos de dados não-relacionais, e foi criado com o objetivo de atender aos requisitos de gerenciamento de grandes volumes de dados, semi-estruturados ou não estruturados, que necessitam de alta disponibilidade e escalabilidade. A necessidade de se criar esse novo tipo de banco de dados, nasceu devido aos bancos de dados tradicionais não conseguirem atender a esses requisitos. Os banco de dados relacionais nasceram na década de 70, quando as aplicações de banco de dados lidavam com dados estruturados, e também vale ressaltar que o volume dos dados gerados naquela época nem se compara com o volume de dados gerados pelas redes sociais atualmente. Assim as empresas que hoje trabalham com grandes volumes
  • 4. de dados e precisam de uma alta disponibilidade e escalabilidade dos mesmos, adotaram a essa nova tecnologia, podemos citar como exemplo a Google, Amazon, Facebook e LinkeIn. Alguns bancos de dados NoSQL fornecem maior taxa de transferência de dados do que os bancos tradicionais. Como por exemplo o Google consegue processar 20 Petabytes por dia armazenadas em BigTable. Os bancos de dados NoSQL são projetados para escalar bem em direção horizontal e não depender de hardware. Assim as máquinas podem ser adicionadas ou removidas sem nenhum problema. 2.2 PRINCIPAIS CARACTERÍSTICAS Os Banco de Dados NoSQL tem algumas características que os diferenciam dos banco de dados tradicionais, essas características são de suma importância para o armazenamento adequado de grandes volumes de dados não estruturados ou semiestruturados, dentre essas características podemos citar:  Escalabilidade Horizontal: A medida que um volume de dados cresce, é necessário que se aumente a escalabilidade, para que o desempenho não caia. Para solucionar esse problema temos dois tipos de escalabilidade, a escalabilidade vertical e a escalabilidade horizontal. A escalabilidade vertical consiste em aumentar o poder de processamento e armazenamento das máquinas. Já a escalabilidade horizontal consiste em aumentar o número de máquinas disponíveis. Analisando os dois tipos de escalabilidade, o mais viável tende a ser a escalabilidade horizontal, porém esse tipo de escalabilidade requer que vários processos de uma tarefa sejam criados e distribuídos, ou seja quando uma tarefa for iniciada ela será dividida em processos e distribuída pelas máquinas. Usar um banco de dados relacional com esse tipo de escalabilidade seria inviável, porque uma vez que diversos processos conectando uma ao mesmo tempo um conjunto de dados causaria uma alta concorrência, aumentando o tempo de acesso ás tabelas envolvidas. Uma característica fundamental dos bancos de dados NoSQL é a ausência de bloqueios, isso permite que a escalabilidade horizontal se torne uma tecnologia adequada para a solução dos problemas de gerenciamento de volumes de dados. Existem várias técnicas para que se alcance a estabilidade horizontal, uma muito conhecida é o Sharding, que consiste em dividir os dados em múltiplas tabelas a serem armazenadas ao longo de diversos nós de uma rede.  Ausência de esquema ou esquema flexível: Uma das principais características dos bancos de dados NoSQL é ausência completa ou quase total do esquema que define a estrutura dos dados modelados. Devido a essa ausência há uma fácil aplicação da escalabilidade e também um aumento na disponibilidade. Mas também devido a essa ausência, não há garantia da integridade dos dados.  Suporte a Replicação: Os banco de dados NoSQL permitem a replicação de uma forma nativa o que provém uma escalabilidade maior e também uma diminuição do tempo gasto para a recuperação de informações. Os bancos
  • 5.   NoSQL conseguem implementar as duas formas de replicação, a Master-Slave (Mestre-Escravo) e a Master-to-Master (Mestre-Mestre). API Simples para fácil acesso dos dados: Como o intuito do NoSQL é fazer com que o acesso aos dados seja feito de uma forma rápida, oferecendo alta disponibilidade e escalabilidade, ele está totalmente focado para que à recuperação dos dados seja feita de forma eficiente, ignorando em como os dados serão armazenados. Para que esse objetivo seja alcançado APIs que facilitam o acesso às informações são desenvolvidos, permitindo assim que qualquer aplicação possa ter acesso aos dados do banco de forma rápida e eficiente. Nem sempre Consistente: Outra característica importante dos bancos de dados NoSQL é que eles nem sempre conseguem se manter consistentes. Esta característica tem como princípio o teorema CAP, que diz que, em um certo momento, só há garantia de duas das três propriedades estejam ativas. 2.3 TÉCNICAS PARA IMPLEMENTAÇÃO Existem algumas técnicas muito importantes para que a implementação de todas as funcionalidades do NoSQL sejam eficientes. Alguns exemplos são:  Map/Reduce: O Map/Reduce dá suporte ao manuseio de grandes volumes de dados distribuídos ao longo dos nós de uma rede. Essa técnica é dividida em duas fases, a primeira é fase de Map onde os problemas são quebrados e divididos em subproblemas, depois são distribuídos entre os nós da rede. A segunda é fase de Reduce, nela os subproblemas são resolvidos em cada nó filho e o resultado é repassado ao pai, que, sendo ele também ele filho, repassaria ao seu pai, e assim por diante até chegar ao nó raiz do problema.  Consistent Hashing: O Consistent Hashing tem a função de suportar o mecanismos de armazenamento e recuperação em bancos de dados distribuídos.  Multiversion Concurrency control (MVCC): O MVCC é um mecanismo que dá suporte a transações paralelas em um banco de dados. Por não utilizar bloqueios ele permite que operações de leitura e escrita sejam efetuadas simultaneamente, diferente do esquema clássico de gerenciamento de transações.  Vector clocks: Como há a possibilidade de muitas operações estarem sendo executadas simultaneamente sobre o mesmo item de dado distribuído é importante determinar qual versão do dado distribuído é a mais atual. Isso é possível graças ao Vector Clocks. 2.4 PRINCIPAIS TIPOS Existem vários tipos de modelos de dados NoSQL. Falaremos de 4 tipos principais desse modelos. São eles: Chave-Valor (Key-Value), Orientado a Documentos, Orientado a Colunas e Orientado a Grafos.
  • 6. 2.5 BANCO DE DADOS CHAVE-VALOR (key-value) Este modelo é bem simples e nos permite a visualização do banco de dados como uma grande tabela hash. Da maneira mais simples possível, todo o banco de dados é composto por um conjunto de chaves, chaves que estão associadas a um único valor. Na figura 1.0 temos um exemplo de como é armazenado um dado em um banco de dados chave-valor, nessa figura podemos ver os campos e suas instancias. A chave representa o campo, como por exemplo Nome, Idade, Sexo e Fone e o Valor representa a própria instancia para o campo que corresponde. Por este modelo ser de fácil implementação, ele permite que os dados sejam acessados muito rapidamente pela chave, isso principalmente em sistemas que possuem alta escalabilidade o que também contribui para no aumento da disponibilidade de acesso aos dados. Em relação a manipulação dos dados, as operações são bem simples como por exemplo o get( ) (Usado para retorna o valor) e o set( ) (Usado para Capturar o valor). Uma das desvantagens desse modelo é que ele não permite a recuperação de objetos por meio de consultas mais complexas. Um bom exemplo de Banco de dados que adota esse modelo é o Dynamo, desenvolvido pela Amazon, posteriormente foi utilizado como base para o desenvolvimento do Cassandra (banco de dados desenvolvido para o Facebook). Com o Dynamo podemos realizar particionamento, replicação e versionamento dos dados. Além do Dynamo, temos outros banco de dados que seguem o modelo chave-valor são eles: Redis, Riak e o GenieDB. 2.6 BANCO DE DADOS ORIENTADO A COLUNAS O modelo orientado a colunas é um pouco mais complexo que o modelo chave-valor. Neste tipo de modelo os dados são indexados por uma tripla (linha, coluna e timestramp), onde as linhas e as colunas são identificadas por chaves e o timestramp é o que permite identificar as diferentes versões de um mesmo dado. Em um banco de dados orientado a colunas as operações de leitura e escrita são atômicas, ou seja, todos os valores associados a uma linha são considerados na execução da operação de leitura ou escrita. Um outro conceito importante sobre esse modelo é o de família de colunas (column family), é usado com o objetivo de agrupar colunas que armazenam o mesmo tipo de dados.
  • 7. Este modelo de surgiu com o BigTable da Google. Suas principais características são: Permitir particionamento, oferecer forte consistência e não garantir alta disponibilidade. 2.7 BANCO DE DADOS ORIENTADO A DOCUMENTOS Este modelo armazena coleções de documentos. Um documento no geral, é um objeto com um código único e um conjunto de campos, que podem ser strings, listas ou documentos aninhados. A estrutura desses campos se parecem com a estrutura dos campos do modelo chave-valor. No modelo de chave-valor, uma única tabela hash é criada para todo o banco de dados. Já no modelo orientado a documentos, temos um conjunto de documentos e em cada documento temos um conjunto de chaves (campos) cada uma com sua chave (key). Um outra característica importantes sobre este modelo é que ele não depende de um esquema rígido, ou seja, não há exigência de uma estrutura fixa. Desse jeito é possível ocorrer uma atualização na estrutura do documentos sem causar problema algum ao banco de dados. Por exemplo a adição de novos campos ao documento não causará nenhum problema ao banco. Essa facilidade e flexibilidade em atualizar a estrutura dos documentos é uma das grandes e principais vantagens do modelo orientado a documentos. Dentre os bancos de dados que utilizam esse modelo podemos citar o CouchDB e o MongoDB. 2.8 BANCO DE DADOS ORIENTADO A GRAFOS O modelo orientado a grafos possui três componentes básicos: os nós (são os vértices do grafo), os relacionamentos (são as arestas) e as propriedades (ou atributos) dos nós e relacionamentos. Neste modelo, o banco de dados pode ser comparado com um multigrafo rotulado e direcionado, onde cada nó pode ser conectado por mais de uma aresta. A utilização de banco de dados orientado a grafos é vantajosa quando consultas complexas são exigidas pelo usuário, se comparado com o modelo conceitual onde essas consultas teriam uma implementação enorme e perca de desempenho, nos bancos de dados orientados a grafos esse tipo de consulta teria uma ganho de performance o que permitiria um melhor desempenho das aplicações. Exemplos de banco de dados baseados em grafos são: Neo4j, AllegroGraph e Virtuoso. Figura 1.1 – Exemplo de BD Orientado a Grafos
  • 8. 3.1 BASE VS ACID Hoje a internet com seus sites, blogs, redes sociais, etc criam uma enorme quantidade de dados, dados que precisam ser processados, analisados e entregues aos usuários que os requisitam. As empresas, organizações ou indivíduos que oferecem aplicações ou serviços nesta área tem que determinar suas necessidades individuais em relação ao desempenho, confiabilidade, disponibilidade, consistência e durabilidade. Para a maioria das aplicações web, especialmente as de grande escala, a disponibilidade e tolerância a partição são mais importantes do que a consistência. Estas aplicações têm que ser confiáveis, o que implica em disponibilidade e redundância. Estas propriedades são difíceis de se alcançar usando as propriedades ACID, assim se opta por usar as propriedades de BASE. A BASE perde as propriedades de consistência e isolamento em favor de ganhar “disponibilidade e ganho de performance”. Para entendermos melhor, explicaremos as propriedades ACID e em seguida as de BASE:  A – Atomicidade: A propriedade de atomicidade garante que as transações sejam atômicas (indivisíveis). A transação será executada totalmente ou não será executada.  C – Consistência: A propriedade de consistência garante que o banco de dados passará de uma forma consistente para outra forma consistente.  I – Isolamento: A propriedade de isolamento garante que a transação não será interferida por nenhuma outra transação concorrente.  D – Durabilidade: A propriedade de durabilidade garante que o que foi salvo, não será mais perdido. Como já dito anteriormente, hoje as aplicações web movimentam uma grande quantidade de dados, e assim elas não conseguem manter todas as propriedades ACID e um bom desempenho das aplicações ao mesmo tempo, desse jeito as empresas optaram por perder uma das propriedades para suprir suas necessidades mais importantes. E então surge as propriedades de BASE que são:  BA – (Basically Available) Basicamente Disponivel – Prioridade na disponibilidade dos dados.  S - (Soft-State) Estado leve – O sistem não precisa ser consistente o tempo todo.  E – (Eventually Consistent) Eventualmente Consistente - Consistente em momento indeterminado. Pode-se resumir as propriedades de Base da seguinte forma: Uma aplicação funciona basicamente todo o tempo (Basicamente Disponível), não tem de ser consistente todo o tempo (Eventualmente Consistente). A seguir temos uma tabela que nôs mostra as principais diferenças entre as propriedades ACID e BASE:
  • 9. ACID Consistência forte Isolamento Concentra-se em "commit" Transações aninhadas Disponibilidade Conservador (pessimista) Evolução difícil (por exemplo, esquema) BASE Fraca consistência Foco em Disponibilidade Melhor esforço Respostas aproximadas Mais simples e mais rápido Agressivo (otimista) Evolução mais fácil Se analisarmos bem a tabela, poderemos ver que as propriedades de BASE se focam mais em Disponibilidade e Desempenho, que são as necessidades mais básicas de uma aplicação web, disponibilizar os dados que o usuário requisitar e fazer isso de uma forma rápida e simples. 4.1 TEOREMA CAP Existem muitas motivos para se usar os bancos de dados NoSQL, como por exemplo usar um modelo mais adequado para os seus dados ou facilitar alterações no esquema, ou até melhorar o desempenho e simplificar a replicação para se alcançar a escalabilidade linear. Como não conseguimos usar todos esses benefícios sem um custo, vamos perder alguma funcionalidade para se ganhar outra. Primeiramente explicaremos cada um dos 3 pontos do Teorema CAP, que são a Consistência, Disponibilidade e a Tolerância a falhas.
  • 10.  Consistency (Consistência): Consistência é a característica que descreve como e se o estado de um sistema fica consistente após uma operação. Num sistema distribuído de dados, isto, normalmente significa que uma vez escrito um registo, este fica disponível para ser utilizado imediatamente, ou seja cada cliente tem sempre a mesma visão dos dados.  Availability (Disponibilidade): Refere-se à concepção e implementação de um sistema de modo que seja assegurado que este permanece ativo durante um determinado período de tempo. Neste contexto, significa que um sistema é tolerante a falhas de software/hardware e normalmente também permanece disponível durante a atualização de software e hardware. Um bom exemplo seria falar que todos os clientes de uma empresa que acessam um a aplicação web, podem sempre ler e atualizar dados na aplicação.  Partition Tolerance (Tolerância ao Particionamento): Refere-se a capacidade de um sistema continuar operando mesmo depois uma falha na rede. Ou seja significa garantir que operações serão completadas, mesmo que componentes individuais não estejam disponíveis. Tolerância ao Particionamento é a capacidade de um sistema se manter operante mesmo em casos onde ocorra uma interrupção parcial de alguns componentes. Explicado os três pontos principais que um sistema web deverá ter, o teorema CAP explica que em sistema distribuído é preciso escolher entre duas dessas propriedade, nunca conseguindo usar as três ao mesmo tempo. Assim é preciso escolher entre Consistência forte, alta disponibilidade e tolerância ao particionamento. Sendo que entre as três propriedades, somente duas podem ser garantidas ao mesmo tempo. Seguindo essa ideia podemos ter três tipos de sistemas: Sistemas CA: Os sistemas com consistência forte e alta disponibilidade (CA) (alta disponibilidade de um nó apenas) não sabem lidar com a possível falha de uma partição. Caso ocorra, sistema inteiro pode ficar indisponível até o membro do cluster voltar. Exemplos disso são algumas configurações clássicas de bancos relacionais. Sistemas CP: Para sistemas que precisam da consistência forte e tolerância a particionamento é necessário abrir a mão da disponibilidade (um pouco). Pode acontecer, caso haja particionamento e o sistema não entre em consenso, que uma escrita seja rejeitada. Claro que os sistemas tentam evitar isso ao máximo, tanto que não costuma existir, por exemplo, uma transação distribuída e sim um protocolo de consensos para garantir a consistência forte. Exemplos desses sistemas CP são BigTable, HBase ou MongoDB entre vários outros. Sistemas AP: Por outro lado existem sistemas que jamais podem ficar offline, portanto não desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo com um tolerância a particionamento é preciso prejudicar a consistência. A ideia aqui é que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento depois (read-consistency). Então pode ter uma janela de inconsistência. Exemplos aqui são Amazon Dynamo, Cassandra ou Riak.
  • 11. 5.1 PARA QUE É INDICADO O NOSQL ? Como dito na introdução o modelo de dados NoSQL é indicado para aplicações que irão trabalhar com enormes quantidades de dados, onde o modelo de dados relacional não atende mais as expectativas dessas aplicações. Uma das principais vantagens no uso de banco de dados não-relacionais está no fato de sua utilização horizontal, ou seja, a distribuição de dados através de bancos disseminados em diferentes servidores, ao contrário do padrão dos bancos mais utilizados e relacionais. Por isso os bancos de dados NoSQL são indicados para grandes cargas de dados, exigências de velocidade na consulta e escrita em grandes volumes de dados. 6.1 PRINCIPAIS PRODUTOS NO MERCADO Os principais bando de dados não-relacionais encontrados hoje são:  MongoDB  CouchDB  Cassandra  Project Valdemort (by Linkedin)  Redis (by Google)  HBase (by Apache)  Dynamo (by Amazon)  dentre muitos outros… 7.1 PRINCIPAIS UTILIZADORES DO NOSQL Os principais utilizadores do NoSQL são é claro as empresas que processam uma enorme quantidade de dados e esses dados devem estar acessíveis de forma rápida, exemplos de empresas que adotaram o modelo NoSQL são:  Google ..................................................................... Banco de dados Bigtable.  Amazon.................................................................... Banco de dados Dynamo.  Yahoo ...................................................................... Banco de dados Hadoop.  Facebook .................................................................. Banco de dados Cassandra.  Digg ......................................................................... Banco de dados Cassandra.  Twitter ..................................................................... Banco de dados Cassandra.  IBM .......................................................................... Banco de dados Cassandra.  Netflix ...................................................................... Banco de dados Cassandra.  LinkedIn .................................................................. Banco de dados Voldemort.  Engine Yard ............................................................. Banco de dados MongoDB. 8.1 INSTALAÇÃO DO BANCO DE DADOS MYSQL NDB CLUSTER Instalaremos uma versão do MySQL Cluster simples em um servidor Linux. Então siga os passos corretamente: 1. Download Baixar o MySQL Cluster através do site: http://dev.mysql.com/downloads/cluster/ certifique-se de selecionar a plataforma correta, neste caso ‘Debian Linux’, e em seguida ‘Debian Linux versão 6.0 (x86, 64-bit), DEB’.
  • 12. 2. Instalação Localize o arquivo que você baixou, extraia e em seguida crie um link para ele: [user1@ws2 ~] $ tar xvf Downloads/4839919.mysql-cluster-advanced7.2.4-linux2.6-x86_64.tar.gz [user1@ws2 ~] $ ln-s mysql-cluster-advanced-7.2.4-Linux2.6-x86_64 mysqlc 3. Configuração Crie pastas para armazenar os arquivos de configuração e os arquivos de dados: [user1@ws2 ~] $ mkdir my_cluster my_cluster / ndb_data my_cluster / mysqld_data my_cluster / conf Dentro da pasta ‘conf’ crie 2 arquivos: My.cnf: [Mysqld] ndbcluster datadir = / home/user1/my_cluster/mysqld_data basedir = / home/user1/mysqlc port = 5000 config.ini: [ndb_mgmd] hostname = localhost datadir = / home/user1/my_cluster/ndb_data NodeId = 1 [ndbd default] noofreplicas = 2 datadir = / home/user1/my_cluster/ndb_data [ndbd] hostname = localhost NodeId = 3 [ndbd] hostname = localhost NodeId = 4 [mysqld] NodeId = 50 Assim como qualquer outro MySQL, o processo requer um banco de dados ‘mysql’ para ser criado e preenchido com os dados essenciais para o sistema.
  • 13. [user1@ws2] $ cd mysqlc [user1@ws2 mysqlc] $ scripts/mysql_install_db --no-defaults -datadir =$HOME/my_cluster/mysqld_data/ 4. Execução Os processos devem ser iniciados na ordem de nó de gerenciamento, nó de dados e por último o MySQL: [userl@ws2 mysqlc]$ cd ../my_cluster/ [userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndb_mgmd –f conf/config.ini –initial – Configdir=$HOME/my_cluster/conf/ [userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndbd –c localhost:1186 [userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndbd –c localhost:1186 Verifique o status do cluster e espere os nós concluírem para que você possa iniciar o servidor MySQL: [userl@ws2 my_cluster]$ $HOME/mysqlc/bin/ndb_mgm –e show Connected to Management Server at: localhost: 1186 Cluster Configuration ------------------------[ndbd (NDB)] 2 node(s) id=3 @127.0.0.1 (mysql-5.5.19 ndb-7.2.4, Nodegroup: 0, Master) id=4 @127.0.0.1 (mysql-5.5.19 ndb-7.2.4, Nodegroup: 0) [ndb_mgmd(MGM) ] 1 node(s) id=1 @127.0.0.1 (mysql-5.5.19 ndb-7.2.4) [mysqld(API)] 1 node(s) Id=50 (not connected, accepting connect from any host) [userl@ws2 my_cluster]$ defaults-file=conf/my.cnf & $HOME/mysqlc/bin/mysqld – 5. Teste Conecte-se ao servidor MySQL e crie uma tabela. [userl@ws2 my_cluster]$ $HOME/mysqlc/bin/mysql –h 127.0.0.1 –P 5000 –u root mysql> create database clusterdb; mysql> use clusterdb; mysql> create table simples ( id int not null primary key )engine = ndb;
  • 14. mysql> insert into simples values (1),(2),(3),(4); mysql> select * from simples; +----+ | id | +----+ | 3 | | 1 | | 2 | | 4 | +----+ 9.1 CONCLUSÃO Devemos ressaltar quais são os focos principais do NoSQL que são a performance, ou seja o desempenho das aplicações mediante a uma enorme quantidade de dados a ser processados. E a escalabilidade horizontal , que é capacidade de se aumentar a capacidade de processamento dos dados adicionado mais servidores a rede. Também devemos ressaltar a simplicidade e facilidade na implantação e uso dos bancos de dados NoSQL, bem como seus ótimos resultados. Mas um ponto comum entre as empresas que têm adotado essa tecnologia, são alguns problemas enfrentados pelas mesmas quando fazem uso de uma grande quantidade de dados, e estes dados precisam ser compartilhados com extrema rapidez. Para que esse problema seja resolvido, é necessário que as aplicações sejam escaláveis e seus dados tenham uma alta disponibilidade. Temos que deixar claro que a solução NoSQL não veio substituir o modelo relacional, mas sim tentar suprir as novas necessidades das aplicações tem, fazendo com que possam gerenciar os seus dados de uma forma mais eficiente. Permitindo que as aplicações tenham vantagens como: Alta disponibilidade dos dados, escalabilidade, esquema flexível, alto desempenho e gerenciamento de dados semi-estruturados. Em troca de tudo isso vale lembrar que nem sempre vai ser possível garantir que os dados estejam consistentes, que haja um controle na concorrência, dentre outras características dos banco de dados tradicionais.
  • 15. 10.1 REFERÊNCIAS BIBLIOGRÁFICAS  NOSQL :  http://blog.hostdime.com.br/materias/tecnologia/mysql-postgresql-ms-sql-servernao-e-a-vez-do-nosql/   NoSQl no Desenvolvimento de Aplicações WEB colaborativas – Bernadette Farias Lóscio (bfl@cin.ufpe.br), Hélio Rodrigues de Oliveira (fro@cin.ufpe.br), Jonas César de Sousa Pontes (jcs@cin.ufpe.br).  http://imasters.com.br/artigo/21781/banco-de-dados/escolhendo--a-ferramentacerta-para-o-banco-de-dados-nosql/    http://www.slideshare.net/mdediana/no-sqlvantagensdesvantagensecompromissos http://www.devmedia.com.br/introducao-aos-bancos-de-dados-nosql/26044 http://ccsl.ime.usp.br/wiki/images/2/20/NoSQL_Vantagens_Desvantagens_e_Com promissos.pdf BASE vs ACID  http://ssdi.di.fct.unl.pt/bd/docs/slides/aula15.pdf  http://blog.lucasrenan.com/propriedades-acid/  TEOREMA CAP  http://blog.caelum.com.br/nosql-do-teorema-cap-para-paccl/  http://blog.nahurst.com/visual-guide-to-nosql-systems  http://elemarjr.net/2011/08/11/cap-theorem-e-alternativa-para-o-acid/  MySQL NDB Cluster:  http://www.clusterdb.com/mysql-cluster/mysql-cluster-manager-1-1-2-creating-acluster-is-now-trivial/  http://dev.mysql.com/downloads/mirror.php?id=413395