sábado, 5 de outubro de 2013

O que é RAID?


RAID? Pode utilizar banco de daods, bom vamos lá.

Bom vamos falar de Raid e explicar um pouco de armazenagem focando banco de dados. Vamos entender um pouco sobre o que é
RAID 0 - RAID 1 - RAID 5 e Spannin.

Redundant Array of Independent Drives, também denominado Redundant Array of Inexpensive Drives, mais conhecido como simplesmente RAID ou ainda em português: Conjunto Redundante de Discos Independentes ou também Conjunto Redundante de Discos Econômicos ou ainda Arranjo Redundante de Discos Independentes, é um meio de se criar um sub-sistema de armazenamento composto por vários discos individuais, com a finalidade de ganhar segurança e desempenho.

Popularmente, RAID seriam dois ou mais discos (por exemplo, HD ou disco rígido) trabalhando simultaneamente para um mesmo fim, por exemplo, citando o exemplo de RAID-1 logo abaixo, serviria como um espelhamento simples, rápido e confiável entre dois discos, para fazer o backup de um disco em outro. Apesar do RAID oferecer segurança e confiabilidade na adição de redundância e evitar falhas dos discos, o RAID não protege contra falhas de energia ou erros de operação. Falhas de energia, código errado de núcleo ou erros operacionais podem danificar os dados de forma irrecuperável.

Surgindo em 1988, RAID foi proposto por David A. Patterson, Garth A. Gibson e Randy H. Katz na publicação "Um Caso para Conjuntos de Discos Redundantes Econômicos (RAID)". Publicado na Conferência SIGMOD de 1988: pp. 109–16.

Bom Raid possui vários níveis e são as várias maneiras de combinar discos para um fim. Vamos lá.



RAID 0 - RAID 1 - RAID 5 e Spanning


RAID 0


RAID 0 - Segmentação (stripping) é um método de mapeamento de dados sobre o meio físico de um arranjo, que serve para criar um grande dispositivo de armazenamento. Os dados são subdivididos em segmentos consecutivos ou stripes que são escritos seqüencialmente através de cada um dos discos de um arranjo. Cada segmento tem um tamanho definido em blocos.

Um arranjo desse tipo pode oferecer uma melhor performance, quando comparada a um disco individual, se o tamanho de cada segmento for ajustado de acordo com a aplicação que utilizará o arranjo:

Em um ambiente com uso intensivo de E/S ou em um ambiente de banco de dados onde múltiplas requisições concorrentes são feitas para pequenos registros de dados, um segmento de tamanho grande é preferencial. Se o tamanho de segmento para um disco é grande o suficiente para conter um registro inteiro, os discos do arranjo podem responder independentemente para as requisições simultâneas de dados.

Em um ambiente onde grandes registros de dados são armazenados, segmentos de pequeno tamanho são mais apropriados. Se um determinado registro de dados extende-se através de vários discos do arranjo, o conteúdo do registro pode ser lido em paralelo, aumentando o desempenho total do sistema.


RAID-1


RAID-1 - A forma mais simples de arranjo tolerante a falhas é o RAID-1. Baseado no conceito de espelhamento (mirroring), este arranjo consiste de vários grupos de dados armazenados em 2 ou mais dispositivos. Apesar de muitas implementações de RAID-1 envolverem dois grupos de dados (daí o termo espelho - mirror), três ou mais grupos podem ser criados se a alta confiabilidade for desejada.

Se ocorre uma falha em um disco de um arranjo RAID-1, leituras e gravações subseqüentes são direcionadas para o(s) disco(s) ainda em operação. Os dados então são reconstruídos em um disco de reposição (spare disk) usando dados do(s) disco(s) sobreviventes. O processo de reconstrução do espelho tem algum impacto sobre a performance de E/S do arranjo, pois todos os dados terão de ser lidos e copiados do(s) disco(s) intacto(s) para o disco de reposição (spare disk).

RAID-1 oferece alta disponibilidade de dados, porque no mínimo 2 grupos completos são armazenados. Conectando os discos primários e os discos espelhados em controladoras separadas, pode aumentar a tolerância a falhas pela eliminação da controladora como ponto único de falha.
Dentre os não híbridos, este nível tem o maior custo de armazenamento por requerer capacidade suficiente para armazenar no mínimo 2 grupos de dados. Este é melhor adaptado para servir pequenas base de dados ou sistemas de pequena escala que necessitem confiabilidade.


RAID-5


RAID-5 - Este tipo de RAID largamente usado funciona similarmente ao RAID 4, mas supera alguns dos problemas mais comuns sofridos por esse tipo. As informações sobre paridade para os dados do arranjo são distribuídas ao longo de todos os discos do arranjo, ao invés de serem armazenadas em um disco dedicado.

Essa idéia de paridade distribuída reduz o gargalo de escrita (write bottleneck) que era o único disco de um RAID-4, porque agora as escritas concorrentes nem sempre requerem acesso às informações sobre paridade em um disco dedicado. Contudo, a performance de escrita geral ainda sofre por causa do processamento adicional causado pela leitura, recálculo e atualização da informação sobre paridade.

Para aumentar a performance de leitura de um arranjo RAID-5, o tamanho de cada segmento em que os dados são divididos pode ser otimizado para a aplicação que estiver usando o arranjo. A performance geral de um arranjo RAID-5 é equivalente ao de um RAID-4, exceto no caso de leituras seqüenciais, que reduzem a eficiência dos algoritmos de leitura por causa da distribuição das informações sobre paridade.

Como em outros arranjos baseados em paridade, a recuperação de dados em um arranjo RAID-5 é feita calculando a função XOR das informações dos discos restantes do arranjo. Pelo fato de que a informação sobre paridade é distribuída ao longo de todos os discos, a perda de qualquer disco reduz a disponibilidade de ambos os dados e informação sobre paridade, até a recuperação do disco que falhou. Isto pode causar degradação da performance de leitura e de escrita.


Sobre o Spanning (Linear)


Spanning, que não é um modo RAID, combina todas as unidades do sistema em um grande volume, de modo que elas atuem como uma unidade gigante. As unidades são preenchidas uma a uma. A vantagem de usar este modo é que você pode adicionar mais unidades sem precisar reformatar o sistema.




Bom pessoal acho que consegui passar um pouco sobre RAID's.

A grande ideia é o armazenamento de banco de dados porém alguns ambientes não tem um desempenho bom devido arquitetura, Mas segue a dica e espero que ajude.

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.

sábado, 31 de agosto de 2013

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!
 Copyright © 2008-2010 All Right Reserved - Todos os Direitos Reservados Elder Stroparo