ARQUITETURA
Voldemort não é um banco de dados relacional, nem objeto ele não tenta satisfazer as necessidades de relações arbitrárias de entidades.
Inicialmente desenvolvido pelo pessoal do Linkedin, ele é um sistema de arquivos distribuídos, uma rede de computadores onde a informação é armazenada em mais de um nó com escalabilidade horizontal e muito mais elevada disponibilidade sendo esse controle baseado em APIs (conjuntos de rotinas e padrões de programação).
MODELAGEM
Dentro da arquitetura suportada polo Voldemort necessitamos de uma modelagem flexível e não relacional (NoSQL) que pode atingir altos níveis de complexidades conforme a escalabilidade do projeto, tendo como suporte os seguintes recursos:
- JSON – Um binário, o modelo de dados que suporta listas, mapas, datas, booleans e números de várias precisões;
- String – Cadeias de texto;
- Java Serialization – Armazenamento de objetos java;
- Protobuf – Protocolo de buffer para o formato de geração de códigos de serialização do Google;
- Thrift – Outro formato de serialização por geração de código;
- Avro-generic / Avro-specifc / Avro-reflective – Outro rico sistema de serialização;
- Identity – Desativa a serialização, apresentando o exato byte[].
VANTAGENS
- Reflete a estrutura organizacional — fragmentos do banco de dados estão localizados nos departamentos que se relacionam com os dados que estes persistem.
- Autonomia Local — um departamento pode controlar seus dados (já que é o mais familiarizado com estes):
- Maior disponibilidade — uma falha em um banco de dados afetará somente um fragmento, ao invés do banco de dados inteiro;
- Melhor performance — os dados estão localizados próximo do local de maior demanda e os sistemas de banco de dados por si só são paralelizáveis, permitindo carregar no banco de dados para o balanceamento entre servidores (a elevada carga em um módulo do banco de dados não irá afetar os outros módulos de banco de dados em um banco de dados distribuído);
- Econômico — custa menos criar uma rede de pequenos computadores com o mesmo poder que um único computador maior;
- Modularidade — sistemas podem ser modificados, adicionados ou removidos do banco de dados distribuído sem afetar os outros módulos (sistemas).
DESVANTAGENS
- Complexidade — trabalho extra deve ser feito pelos DBAs para garantir que a natureza da distribuição do sistema seja transparente. Trabalho extra deve ser feito para manter sistemas múltiplos diferentes, ao invés de um único grande. Design de banco de dados extra deve também ser feito para levar em conta a natureza desconectada do banco de dados - por exemplo, joins tornam-se proibitivamente caros quando são rodados entre múltiplas plataformas;
- Implantação mais cara — o aumento da complexidade e uma infraestrutura mais extensa significa custo extra de trabalho;
- Segurança — fragmentos de banco de dados remotos devem ser seguros e, como eles não são centralizados então os lugares remotos também devem ser seguros. A infraestrutura também deve ser segura (por exemplo, pela encriptação dos links de rede entre os lugares remotos);
- Difícil de manter a integridade — em sistemas distribuídos, reforçar a integridade ao longo de uma rede pode exigir demais dos recursos da rede para ser viável;
- Inexperiência — Dificuldades no gerenciamento. Pode ser difícil trabalhar com banco de dados distribuídos e como é uma área relativamente nova ainda não há tantos casos (ou experiências) práticos de seu uso disponíveis como exemplo;
- Falta de padrões – ainda não há metodologias e ferramentas para ajudar usuários a converter um SGBD centralizado para um SGBD distribuído;
- Design do banco de dados mais complexo – além das dificuldades normais, o design de um banco de dados distribuídos tem que considerar a fragmentação dos dados, alocação dos fragmentos em lugares específicos e a replicação de dados.
QUEM USA
- Glit Groupe
Comentários
Postar um comentário