No post anterior nós falamos sobre os problemas que levaram a criação dos bancos de dados NoSQL.Uma diferença importante é que na maior parte dos casos estes procedimentos são feitos automaticamente facilitando assim a vida dos desenvolvedores.
Técnicas mais usadas para escalar bancos de dados
As técnicas utilizadas pelos bancos NoSQL são muitas vezes as mesmas que os programadores experientes em bancos de dados relacionais tem utilizados por anos para escalar seus sistemas mas de uma maneira otimizada e muitas vezes automática. “O que vale é usar a ferramenta certa.” não esperem que um banco de dados NoSQL vai ser uma silver bullet para os seus problemas de escalabilidade, em alguns casos vai ser tão difícil escalar um banco não relacional quanto um banco relacional. Por isso é importante entender as ferramentas disponíveis para fazer o melhor uso possível das suas capacidades.
Replicação – Escalar por duplicação de informações
Neste caso nós copiamos as informações em mais de um banco para aumentar nossa capacidade de recuperar estas informações. Podemos dividir em duas “arquiteturas” principais:
Master-Slave:
Cada escrita em banco resulta em N x escritas onde N é o número de slaves. Neste caso temos um banco “Master” que propaga cada write para os bancos “slaves”. Isto aumenta a nossa velocidade de leitura mas não melhora em nada nossa capacidade de escrita. Muitos desenvolvedores entendem hoje como “escalabilidade” simplesmente adicionar mais um slave em seu banco de dados. Isto pode ser uma boa solução inicial caso a maior parte da carga do seu banco venha de leituras. Porém esta estratégia não é recomendada para casos em o volume de escrita é muito grande.
Multi-Master:
Aumentamos o número de Masters em nosso sistema e assim aumentamos nossa capacidade de escrita. Esta abordagem pode gerar conflitos. Existem muitas técnicas para resolução de conflitos. Isto vai além do escopo deste post. Se você quiser se aprofundar mais no assunto leia este paper da microsoft.
Sharding – Escalando por divisão
Uma alternativa muito conhecida é o Sharding. Dividimos os dados em múltiplas tabelas do banco para escalar tanto nossas leituras como nossas escritas. Isto traz o grande problema de “quebrar” a lógica de relacionamentos o que é o grande forte dos bancos relacionais. As aplicações tem que resolver a complexidade gerada pela partição de informações como por exemplo a execução de joins e outros comandos. Fazer sharding manualmente não é simples e exige considerável esforço da equipe de desenvolvimento.
No caso dos bancos de dados NoSQL muitas destas mesmas técnicas que eu acabei de descrever são utilizadas. Porém em geral elas são invisíveis para o desenvolvedor o que facilita o desenvolvimento de aplicações para dados em larga escala. Porém o ecossistema que está surgindo em torno do termo “NoSQL” é muito grande e diversificado tornando assim difícil a tarefa de fazer generalizações. Vamos então tentar utilizar algumas das características básicas dos bancos não relacionais para poder classificá-los.
Classificação de bancos de dados NoSQL
Existem hoje um grande número de sistemas que se enquadram no conceito de NoSQL vamos separar estes sistemas de acordo com 4 características principais : Arquitetura,Armazenamento, Modelo de Dados.
Arquitetura
Quanto a arquitetura podemos dividir os bancos de dados NoSQL em dois tipos : distribuídos e não distribuídos. Os distribuídos tomam a responsabilidade pela partição dos dados e pela sua replicação.
Distribuidos:
- Amazon Dynamo
- Scalaris
- Voldemort
- CouchDb (thru Lounge)
- Riak
- MongoDb (in alpha)
- BigTable
- Cassandra
- HyperTable
- HBase
Não distribuídos:
- Redis
- Tokyo Tyrant
- MemcacheDb
- Amazon SimpleDb
Armazenamento
Podemos dividir os sistemas entre aqueles que armazenam dados em disco e os que armazenam na memória. Esta diferenciação é importante por que no caso da gravação em disco você vai precisar de um cache explicito. Já os dados armazenados em memória não são duráveis.
Memória:
- Scalaris
- Redis
Disco:
- CouchDb
- MongoDb
- Riak
- Voldemort
Configurável
- BigTable
- Cassandra
- Hbase
- HyperTable
Modelo de dados
Chave/Valor
- Amazon Dynamo
- Amazon S3
- Redis
- Scalaris
- Voldemort
Documento
- Amazon SimpleDb
- Apache Couchdb
- MongoDb
- Riak
Colunas
- Cassandra
- Google BigTable
- HBase
- Hyperbase
Grafo
- Neo4j
- InfoGrid
- Sones
- HyperGraphDB
Escrito por: Edmar Ferreira