modelos de distribuição e consistência
TRANSCRIPT
Modelos de Distribuição e Consistência
Edson de Lima ([email protected])Gabriela de Andrade ([email protected])
João Farias ([email protected])Leonardo Borges ([email protected])
Por que Distribuir?
§ Aumento do volume de dados.
§ Custo dos servidores
§ Dificuldade de adaptação de um novo servidor.
Replication e Sharding
§ Replication: faz copia os dados em vários nós.
§ Pode ser do tipo Peer-to-peer ou Master-Slave.
§ Sharding: copia dados diferentes em diferentes nós.
Single Server
§ Executa todas as operações de leitura e gravação de dados em uma única máquina.
§ Mais simples de gerenciar e desenvolver aplicações.
§ É o mais comum e mais recomendado devido a sua praticidade.
Sharding
§ Modelo em que o banco de dados é dividido e fragmentos e armazenados em instâncias de servidor.
§ Desenvolvimento não muito trivial.
§ Dificuldade de distribuir todas as consultas para os fragmentos.
§ Auto-Sharding – Recurso oferecido por alguns NoSQLdatabases.
§ É mais impactante no processo de leitura do que no de escrita.
§ É mais difícil e caro de manter todos os servidores em bom funcionamento
Master-Slave Replication
§ Replica todos os dados em vários nós e escolhe um deles para ser o Mestre, o restante tornam-se escravos.
§ O mestre é responsável por atualizar os escravos.
§ Útil para um sistema de leitura intensa.
§ Se o mestre falhar os escravos ainda dão conta das solicitações de leitura, porem impossibilita escrita.
§ Mestres podem ser nomeados automaticamente ou manualmente.
§ Replicação
Peer-to-Peer Replication
§ Semelhante ao Master-slave, porém todos são mestres.
§ Problemas de consistência devido a possibilidade de dis usuários alterarem o mesmo nó.
Sharding e Replication
§ União de master-slave com sharding.
§ Vários nós em um cluster com fragmentação dos dados sobre eles
Consistência de Atualização
§ Update (conflito de gravação)
§ Pessimista → Locks
§ Otimista → Detecção de Erros
§ Single-Server → Serialização
§ Distributed System
Consistência de Leitura§ Read-Write Conflict
Consistência de Leitura§ Consistência Lógica.
Ø SGBDs relacionais → Transições.
Ø (Maioria) dos NoSQL → Janela de inconsistência.
Consistência de Leitura§ Quando se adiciona réplicas.
Ø Consistência da replicação.
Ø Mesmos itens de dados → Mesmo valor quando lido por réplicas diferentes
Consistência de Leitura
§ Quando se adiciona réplicas.
Ø Inconsistência consigo devido a janela de inconsistência
● “Onde está meu comentário?”
Ø Consistência Read-Your-Writes
● Afinidade de Sessão
Relaxamento de Consistência
§ Consistência tem um custo
§ Tradeoff: Performance e habilidade de fragmentar
§ Teorema CAP
ØConsistência
ØDisponibilidade
● Se você falar de um nó, esse nó pode ler e escrever
ØTolerância a Partição
● Cluster sobrevive a quebra de outras partições
§ Só se pode ter duas das três acima.
Relaxamento de Consistência§ Distribuição de sistemas.
Ø Tem tolerância a partição.
Ø Tradeoff entre consistência e disponibilidade.
Ø Exemplo:
§ Comunicação para garantir a consistência e disponibilidade de mortes.
§ Melhora-se na disponibilidade usando um Mestre.
Ø Na prática,
§ Não consistência vs disponibilidade, mas consistência vs latência.
§ Adicionar nós para garantir a consistência aumenta o tempo de resposta.
Ø latência muito alta? Dados indisponíveis.
Durabilidade§ Sessão do usuário.
Ø In-memory.
Ø Pode perder sessão.
Ø Mas é melhor que um site lento.
§ Sistemas Distribuídos
Ø Falha na replicação da durabilidade.
● O nó processa uma atualização, mas falha em replicar aos outros nós.
Ø Falha do master-slave.
§ O Mestre irá voltar rápido?
Ø Sim: Não mudar de Mestre Automaticamente
Ø Não: Deve-se espera os escravos serem atualizados antes de responder ao cliente
Quorum
§ Quanto mais nós, mais consistência
§ Escrever no quaruim: W > N / 2.
Ø W -> Nós na gravação.
Ø N -> Fator de Replicação.
§ Quorum de Leitura
§ Consistência Forte: R + W > N
§ Peer-to-Peer
§ Master-slave: Lê e escreve sobre o mestre.