1. O documento discute os bancos de dados NoSQL, incluindo suas principais características como escalabilidade horizontal, ausência de esquema e suporte à replicação.
2. Os principais tipos de bancos de dados NoSQL são discutidos: chave-valor, orientado a colunas, orientado a documentos e orientado a grafos.
3. Técnicas como MapReduce, consistent hashing e MVCC são explicadas como formas de implementar bancos de dados NoSQL de forma eficiente.
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