História Apache Cassandra - NoSQL

Banco de dados  Apache Cassandra

Banco de dados  Apache Cassandra

O banco de dados Cassandra “Apache” é a escolha certa quando você precisar de escalabilidade e alta disponibilidade, sem comprometer o desempenho.

Escalabilidade linear e comprovada tolerância a falhas em hardware e infraestrutura em geral. A nuvem tornam a plataforma perfeita para dados de missão crítica como um grande exemplo de um sistema que utiliza o Cassandra é o Facebook e atualmente é mantido pela Apache. O banco de dados Cassandra tem um grande privilégio para replicar em vários servidores, proporcionando tudo isso uma pequena latência para seus usuários, também saiba mais que você pode sobreviver a quedas regionais sem comprometer o ambiente todo. 

O Cassandra é um projeto de sistema de banco de dados distribuído altamente escalável de segunda geração, que reúne a arquitetura do Dynamo, da Amazon e modelo de dados baseado no BigTable, do Google.

O Cassandra inicialmente foi criado pelo Facebook, que abriu seu código-fonte para a comunidade em 2008. Agora é mantido por desenvolvedores da fundação Apache e colaboradores de muitas empresas.

Modelo de dados do Cassandra oferece a conveniência de índices de coluna com o desempenho de atualizações de log-estruturadas, um forte apoio para a desnormalização e visões materializadas e poderoso built-in cache.

Performace: 

Cassandra supera consistentemente alternativas NoSQL populares benchmarks e aplicações reais, principalmente por causa das escolhas arquitetônicas fundamentais.

A ideia desse modelo é estar dando prioridade há uma alta disponibilidade e escalabilidade além de um alto grau de performance.

Também possui um alto nível de armazenamento, com o objetivo da disponibilidade boa parte desse modelo usam memória principal e durante um período de tempo são jogados no disco rígido, alguns modelos trabalham 100% com memória principal.  

Ao descentralizado o Cassandra em instâncias regionais ele não há pontos únicos de falha. Não há pontos de estrangulamento da rede. Cada nó no cluster é idêntica.

Cassandra possui um modelo de persistência com a uma necessidade de se ganhar mais performance principalmente no trabalho com grandes blocos de dados foi criado os bancos que usam este princípio de dados como BASE.

Comprovado a ótima performance do banco de dados NoSQL Cassandra.

Cassandra está em uso em Netflix, eBay, Twitter, Urban Airship, Constant Contact, Reddit, Cisco, OpenX, Digg, Cloudkick, Ooyala, e mais empresas que possuem grandes conjuntos de dados ativos. O maior cluster Cassandra conhecido tem mais de 300 TB de dados em mais de 400 máquinas.

Tolerâncias a falhas:

Os dados são automaticamente replicados para vários nós para tolerância a falhas. Replicação em vários centros de dados é suportado. Nós com falha pode ser substituído sem tempo de inatividade. Mesmo ocorrendo falhas não irá afetar o ambiente de utilização.

Cassandra possui uma grande durabilidade sendo adequado para aplicações que não podem dar ao luxo de perder dados, mesmo quando alguma instância fique fora levando alguns dados para baixo ele não perde o ambiente todo.

Controle:

Cassandra tem vários meios de controle, como.

Replicação síncrona ou assíncrona para cada atualização.

Operações assíncronas altamente disponíveis são otimizados com recursos como Handoff.

Bom é isso ai, eu recomendo para quem tem uma aplicação com alto nível de complexidade na nuvem. Banco de dados ótimo.

Triggers PostgreSQL

Olá, vamos falar hoje sobre Triggers ou Gatilhos.

Irei realizar esse post de acordo com o banco de dados que pertence a este elefante abaixo, espero que vocês saibam de qual banco se trata!

Uma funções de gatilho possui um recurso muito útil quando estamos falando de bancos de dados pois pouco utilizam as Triggers devido a complexidade.

Bom, existem inúmeras formas para se realizar e implementar funções de gatilho. Algumas de uma forma um pouco diferente uns dos outros.

Vamos criar um seguinte exemplo e vamos identificar como funciona os gatilhos no SGBD PostgreSQL.

Sempre uma função de gatilho pode ser criada para executar antes (BEFORE) ou após (AFTER) as consultas INSERT, UPDATE OU DELETE, uma vez para cada registro (linha) modificado ou por instrução SQL. Logo que ocorre um desses eventos do gatilho a função do gatilho é disparada automaticamente para tratar o evento.

No que diz respeito a declaração de um gatilho, para o banco PostgreSQL, sempre devemos atrelar uma FUNÇÃO ao gatilho, enquanto nos demais bancos de dados, o algoritmo a ser executado fica no corpo da declaração do gatilho.

Sintaxe de um TRIGGER em PostgreSQL:

CREATE TRIGGER nome { BEFORE | AFTER } { evento [ OR ... ] ON  tabela [ FOR [ EACH ] { ROW | STATEMENT } ]     EXECUTE PROCEDURE nome_da_funcao ()

Sempre devemos declarar quando a trigger deve ser disparada: antes (BEFORE) ou após (AFTER) um evento (INSERT, UPDATE, DELETE ou SELECT) em determinada tabela, para cada linha (ROW) ou instrução (STATEMENT), e qual função (PROCEDURE) deve ser executada.

Como ficaria no banco de dados:

A tabela de usuários

id	nm_login	ds_senha	fg_bloqueado	nu_tentativa_login
1	hallan	hallan2011	false	0
2	joao	123456	false	0
3	maria	abcd1234	false	2

Vamos usar sempre que um usuário for excluído, guardar as suas informações em uma tabela reserva.

SQL para a criação da tabela de backup:

CREATE TABLE bkp_usuario (   id integer NOT NULL,    nm_login character varying,    ds_senha character varying,    fg_bloqueado boolean,    nu_tentativa_login integer,    data_exclusao timestamp,    CONSTRAINT pk_bkp_usuario PRIMARY KEY (id) );

Temos, então, a seguinte tabela, chamada bkp_usuario:

id

nm_login

ds_senha

fg_bloqueado

nu_tentativa_login

data_exclusao

O próximo passo então é criar a função que será disparada toda vez que um usuário for excluído. Apesar de ser um exemplo simples, serve para o entendimento de um gatilho.

Podemos criar, então, a função da seguinte forma:

CREATE OR REPLACE FUNCTION backup_usuario() RETURNS TRIGGER AS $$   BEGIN     INSERT INTO bkp_usuario     (id, nm_login, ds_senha, fg_bloqueado, nu_tentativa_login, data_exclusao)     VALUES     (OLD.id, OLD.nm_login, OLD.ds_senha,      OLD.fg_bloqueado, OLD.nu_tentativa_login, NOW() );     RETURN NEW;   END; $$ LANGUAGE plpgsql;

A palavra reservada OLD representa o registro antigo (para o caso de um update ou um delete). No corpo da função, estamos apenas lendo os dados do registro antigo e efetuando um insert na tabela de backup. A função NOW() retorna a data e hora atual do sistema.

Com a função pronta, devemos criar o gatilho que fará ela ser disparada toda vez que ocorrer um comando de DELETE na tabela de usuários.

Devemos criar o gatilho da seguinte forma:

CREATE TRIGGER trigger_usuario AFTER DELETE     ON usuario FOR EACH ROW     EXECUTE PROCEDURE backup_usuario();

Nosso gatilho será disparado sempre depois de um comando de exclusão (AFTER DELETE) na tabela de usuário, e para cada linha (FOR EACH ROW) executa a função (EXECUTE PROCEDURE) backup_usuario.

Desta forma, se efetuarmos a seguinte instrução:
Delete from usuario where id=2;

A tabela de usuário ficará da seguinte forma:

id	nm_login	ds_senha	fg_bloqueado	nu_tentativa_login
1	hallan	hallan2011	false	0
3	maria	abcd1234	false	2

E a tabela bkp_usuario ficará da seguinte forma:

id	nm_login	ds_senha	fg_bloqueado	nu_tentativa_login	data_exclusao
2	joao	123456	false	0	2011-11-11 21:01:49.906

Bom acho que deu para entender quando é executado este gatilho somente quando ocorre a exclusão de registro na tabela de usuários. E logo em seguida ele acaba realizando automaticamente o insert na outra tabela backup usuários onde com os registros e a data atuação da execução do gatilho.

Abraço!

O que é Instâncias de Banco de Dados?

O que é Instâncias de Banco de Dados?

Instância nada mais é onde existem os principais componentes de um típico servidor, onde pode ser uma ou mais CPU’s alocando espaço em discos e memória.

Existe alguns casos uma instância sem um banco de dados. Você pode criar uma instância sem problema algum porém, ela não irá realizar acesso a qualquer arquivo de banco de dados, pois ela não está associada com um banco. Ela pode existir sem problema algum mas sem um banco de dados ela seria totalmente inútil.

A importância de uma Instância em um banco de dados serve para poder acessar o banco sem restrições alguma. Você cria sua instância, onde o objetivo é montar ela especificamente para um banco de dados para melhor desempenho.

Você pode configurar múltiplas Instâncias para acessar o mesmo grupo de arquivos ou
banco de dados. Muitas instâncias em vários servidores acessando um banco de dados central permitem escalabilidade e alta disponibilidade de desempenho.

Bom nada mais do que é, ou seja uma instância como falei e volto a falar ela serve para realizar uma combinação da memória e dos processos que são parte de uma instalação em funcionamento e ou a instância é usada para a gerência e acesso ao banco de dados.

Somente informando quando uma instância é iniciada, o banco aloca uma área de memória chamada de SGA (Área do Sistema Global) e inicia um ou mais processos em background. SGA é uma área de memória usada para armazenar informações do banco, que são compartilhadas pelos processos do banco.

Bom é isso ai espero que a explicação seja útil a todos pois sei que poucos entendem uma instância por mais complexa que seja.

Dump

O que é um Dump?

Dump é um programa para sistemas operacionais Unix usado para fazer backups de arquivos de sistema. Este é um dos programas do gênero mais antigos, sendo considerado um dos melhores.

Melhor explicando um Dump nada mais é que um backup.

Vamos entender aprofundadamente utilizando um dump em banco de dados.

Em MySQL você pode usar o seguinte comando (dentro do terminal mysql).

ficaria assim:

Database: meubanco
Host: localhost
Username: nomeusuario
Password: senha

$mysql -h localhost -u nomeusuario -senha meubanco < backup_meubanco.sql

Em Oracle você pode usar o seguinte comando (dentro do terminal Oracle).

ficaria assim: 

Username: user1

Password: senha_do_user1

exp user1/senha_do_user1 file=arquivo_dump.dmp log=log_dump.log

Outro exemplo um pouco diferente mas também é a realização de um Dump.

Vamos pegar um exemplo o SQL Server 2000.

Requisito: É necessário possuir o SQL Server 2000, com a ferramente Enterprise Manager, instalado no ambiente onde o procedimento será executado.

1° - Configurar a conexão com a sua base de dados na Plug In no seu Enterprise Manager, em ambiente de desenvolvimento por exemplo;

2° - Clicando com o botão direito do mouse sobre a sua base já configurada clicar em Tasks > Generate SQL Script para copiar todos os Create Tables da sua base remota;

3° - Utilizar os Create Tables em seu servidor SQL Server local, ambiente de desenvolvimento, para clonar a base de dados remota;

4° - Clicando novamente com o botão direito do mouse sobre a base clonada selecionar em Tasks > Import Data, e informar os dados de origem da base remota;

5° - Clicando novamente com o botão direito do mouse sobre a base clonada selecionar Tasks > Backup.  

Bom pessoal acho que é isso uma breve visão como realizar um dump.

Citei somente em MySQL, Oracle e SQL Server 2000.

Outro post irei fazer especificando mais a cada versão de banco de dados.