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 semi-

estruturados, 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:

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.

ACID BASE

Consistência forte Fraca consistência

Isolamento Foco em Disponibilidade

Concentra-se em "commit" Melhor esforço

Transações aninhadas Respostas aproximadas

Disponibilidade Mais simples e mais rápido

Conservador (pessimista) Agressivo (otimista)

Evolução difícil (por exemplo, esquema) Evolução mais fácil

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-advanced-7.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]$ $HOME/mysqlc/bin/mysqld –defaults-file=conf/my.cnf & 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-server-

nao-e-a-vez-do-nosql/

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

vantagensdesvantagensecompromissos

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-ferramenta-

certa-para-o-banco-de-dados-nosql/

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-a-

cluster-is-now-trivial/

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