Your SlideShare is downloading. ×
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Sistemas NoSQL, surgimento, características e exemplos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sistemas NoSQL, surgimento, características e exemplos

3,612

Published on

Introdução ao Movimento NoSQL; Suas principais características; Técnicas para implementação; Principais tipos; Teorema CAP; Principais produtos no mercado e seus principais utilizadores.

Introdução ao Movimento NoSQL; Suas principais características; Técnicas para implementação; Principais tipos; Teorema CAP; Principais produtos no mercado e seus principais utilizadores.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,612
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
239
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  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

×