🚀 Experimente o Zilliz Cloud, o Milvus totalmente gerenciado, gratuitamente—experimente um desempenho 10x mais rápido! Experimente Agora>>

milvus-logo
LFAI
  • Home
  • Blog
  • Jangada ou não? A melhor solução para a consistência de dados em bancos de dados nativos da nuvem

Jangada ou não? A melhor solução para a consistência de dados em bancos de dados nativos da nuvem

  • Engineering
May 16, 2022
Xiaofan Luan

Cover image Imagem da capa

Este artigo foi escrito por Xiaofan Luan e transcrito por Angela Ni.

A replicação baseada em consenso é uma estratégia amplamente adotada em muitos bancos de dados distribuídos e nativos da nuvem. No entanto, ela tem algumas deficiências e definitivamente não é a solução ideal.

Este post tem como objetivo primeiro explicar os conceitos de replicação, consistência e consenso em um banco de dados distribuído e nativo da nuvem, em seguida, esclarecer por que algoritmos baseados em consenso como Paxos e Raft não são a bala de prata e, finalmente, propor uma solução para a replicação baseada em consenso.

Ir para:

Entendendo a replicação, a consistência e o consenso

Antes de nos aprofundarmos nos prós e contras do Paxos e do Raft, e propormos uma estratégia de replicação de logs mais adequada, precisamos primeiro desmistificar os conceitos de replicação, consistência e consenso.

Note-se que este artigo se concentra principalmente na sincronização de dados/logs incrementais. Por conseguinte, quando se fala de replicação de dados/log, refere-se apenas a replicação de dados incrementais e não de dados históricos.

Replicação

A replicação é o processo de fazer várias cópias de dados e armazená-las em diferentes discos, processos, máquinas, clusters, etc., com o objetivo de aumentar a fiabilidade dos dados e acelerar as consultas de dados. Uma vez que, na replicação, os dados são copiados e armazenados em vários locais, os dados são mais fiáveis face à recuperação de falhas de disco, falhas de máquinas físicas ou erros de cluster. Além disso, várias réplicas de dados podem aumentar o desempenho de uma base de dados distribuída, acelerando consideravelmente as consultas.

Existem vários modos de replicação, tais como a replicação síncrona/assíncrona, a replicação com consistência forte/eventual, a replicação líder-seguidor/replicação descentralizada. A escolha do modo de replicação tem um efeito na disponibilidade e na consistência do sistema. Por conseguinte, tal como proposto no famoso teorema CAP, um arquiteto de sistemas tem de optar entre a consistência e a disponibilidade quando a partição da rede é inevitável.

Consistência

Em suma, a consistência numa base de dados distribuída refere-se à propriedade que garante que cada nó ou réplica tem a mesma visão dos dados quando escreve ou lê dados num determinado momento. Para obter uma lista completa dos níveis de consistência, leia o documento aqui.

Para esclarecer, estamos a falar de consistência como no teorema CAP, e não ACID (atomicidade, consistência, isolamento, durabilidade). A consistência no teorema CAP refere-se ao facto de cada nó do sistema ter os mesmos dados, enquanto a consistência no ACID se refere a um único nó que aplica as mesmas regras em todas as potenciais submissões.

Em geral, as bases de dados OLTP (processamento de transacções em linha) exigem uma forte consistência ou linearização para garantir que

  • Cada leitura pode aceder aos últimos dados inseridos.
  • Se um novo valor for devolvido após uma leitura, todas as leituras seguintes, independentemente de se tratar do mesmo cliente ou de clientes diferentes, devem devolver o novo valor.

A essência da linearização é garantir a recência de múltiplas réplicas de dados - uma vez que um novo valor é escrito ou lido, todas as leituras subsequentes podem ver o novo valor até que o valor seja posteriormente substituído. Um sistema distribuído que ofereça linearização pode poupar aos utilizadores o trabalho de vigiar várias réplicas e pode garantir a atomicidade e a ordem de cada operação.

Consenso

O conceito de consenso é introduzido nos sistemas distribuídos porque os utilizadores estão ansiosos por ver os sistemas distribuídos a funcionar da mesma forma que os sistemas autónomos.

Em termos simples, o consenso é um acordo geral sobre um valor. Por exemplo, o Estêvão e o Francisco queriam ir comer qualquer coisa. Steve sugeriu que comessem sandes. Frank concordou com a sugestão de Steve e ambos comeram sandes. Chegaram a um consenso. Mais especificamente, um valor (sanduíches) proposto por um deles é aceite por ambos, e ambos tomam medidas com base nesse valor. Do mesmo modo, o consenso num sistema distribuído significa que quando um processo propõe um valor, todos os restantes processos do sistema concordam e actuam com base nesse valor.

Consensus Consenso

Replicação baseada no consenso

Os primeiros algoritmos baseados em consenso foram propostos juntamente com a replicação com carimbo de vista em 1988. Em 1989, Leslie Lamport propôs o Paxos, um algoritmo baseado no consenso.

Nos últimos anos, assistimos à predominância de outro algoritmo baseado no consenso no sector - o Raft. Foi adotado por muitas das principais bases de dados NewSQL, como CockroachDB, TiDB, OceanBase, etc.

É de notar que um sistema distribuído não suporta necessariamente a linearização, mesmo que adopte a replicação baseada no consenso. No entanto, a linearização é o pré-requisito para a construção de uma base de dados distribuída ACID.

Ao conceber um sistema de base de dados, deve ser tida em conta a ordem de confirmação dos registos e das máquinas de estado. Também é necessário um cuidado extra para manter o aluguer do líder do Paxos ou do Raft e evitar uma divisão do cérebro sob a partição da rede.

Raft replication state machine Máquina de estado de replicação Raft

Prós e contras

De facto, o Raft, o ZAB e o protocolo de registo baseado em quorum no Aurora são variações do Paxos. A replicação baseada em consenso tem as seguintes vantagens:

  1. Embora a replicação baseada no consenso se centre mais na consistência e na partição da rede no teorema CAP, proporciona uma disponibilidade relativamente melhor em comparação com a replicação tradicional líder-seguidor.
  2. O Raft é um avanço que simplificou bastante os algoritmos baseados no consenso. Existem muitas bibliotecas Raft de código aberto no GitHub (por exemplo, sofa-jraft).
  3. O desempenho da replicação baseada no consenso pode satisfazer a maioria das aplicações e empresas. Com a cobertura de SSDs de alto desempenho e NICs (placa de interface de rede) de gigabytes, o fardo de sincronizar várias réplicas é aliviado, tornando os algoritmos Paxos e Raft os principais no sector.

Uma ideia errada é que a replicação baseada em consenso é a solução ideal para obter consistência de dados numa base de dados distribuída. No entanto, esta não é a verdade. Os desafios em termos de disponibilidade, complexidade e desempenho enfrentados pelo algoritmo baseado em consenso impedem-no de ser a solução perfeita.

  1. Disponibilidade comprometida O algoritmo Paxos ou Raft optimizado tem uma forte dependência da réplica líder, que tem uma fraca capacidade de lutar contra a falha cinzenta. Na replicação baseada no consenso, uma nova eleição da réplica líder não terá lugar até que o nó líder não responda durante um longo período de tempo. Por conseguinte, a replicação baseada no consenso é incapaz de lidar com situações em que o nó líder é lento ou em que ocorre uma falha.

  2. Elevada complexidade Embora já existam muitos algoritmos alargados baseados em Paxos e Raft, o aparecimento de Multi-Raft e Parallel Raft exige mais considerações e testes sobre a sincronização entre registos e máquinas de estado.

  3. Desempenho comprometido Numa era nativa da nuvem, o armazenamento local é substituído por soluções de armazenamento partilhado como o EBS e o S3 para garantir a fiabilidade e a consistência dos dados. Como resultado, a replicação baseada em consenso já não é uma necessidade para sistemas distribuídos. Além disso, a replicação baseada em consenso traz consigo o problema da redundância de dados, uma vez que tanto a solução como o EBS têm várias réplicas.

Para a replicação em vários centros de dados e várias nuvens, a procura de consistência compromete não só a disponibilidade, mas também a latência, resultando numa diminuição do desempenho. Por conseguinte, a linearização não é uma necessidade para a tolerância a desastres em vários centros de dados na maioria das aplicações.

Uma estratégia de replicação de registos para bases de dados distribuídas e nativas da nuvem

É inegável que os algoritmos baseados no consenso, como o Raft e o Paxos, continuam a ser os principais algoritmos adoptados por muitas bases de dados OLTP. No entanto, ao observar os exemplos do protocolo PacificA, Socrates e Rockset, podemos ver que a tendência está a mudar.

Existem dois princípios principais para uma solução que possa servir melhor uma base de dados distribuída e nativa da nuvem.

1. Replicação como um serviço

É necessário um microsserviço separado dedicado à sincronização de dados. O módulo de sincronização e o módulo de armazenamento não devem mais estar fortemente acoplados dentro do mesmo processo.

Por exemplo, o Socrates dissocia o armazenamento, o registo e a computação. Existe um serviço de registo dedicado (serviço XLog no centro da figura abaixo).

Socrates architecture Arquitetura do Socrates

O serviço XLog é um serviço individual. A persistência dos dados é conseguida com a ajuda de um armazenamento de baixa latência. A zona de aterragem no Socrates é responsável por manter três réplicas a uma velocidade acelerada.

Socrates XLog service Serviço XLog do Socrates

O nó líder distribui os registos para o corretor de registos de forma assíncrona e transfere os dados para a Xstore. A cache SSD local pode acelerar a leitura dos dados. Quando a descarga de dados é bem sucedida, os buffers na zona de aterragem podem ser limpos. Obviamente, todos os dados de registo são divididos em três camadas - zona de aterragem, SSD local e XStore.

2. Princípio da boneca russa

Uma forma de conceber um sistema é seguir o princípio da boneca russa: cada camada é completa e perfeitamente adequada ao que a camada faz, para que outras camadas possam ser construídas em cima ou à volta dela.

Ao conceber uma base de dados nativa da nuvem, temos de aproveitar inteligentemente outros serviços de terceiros para reduzir a complexidade da arquitetura do sistema.

Parece que não podemos contornar o Paxos para evitar falhas num único ponto. No entanto, ainda podemos simplificar muito a replicação de logs, entregando a eleição do líder para os serviços Raft ou Paxos baseados em Chubby, Zk e etcd.

Por exemplo, a arquitetura Rockset segue o princípio da boneca russa e utiliza Kafka/Kineses para registos distribuídos, S3 para armazenamento e cache SSD local para melhorar o desempenho das consultas.

Rockset architecture Arquitetura Rockset

A abordagem do Milvus

A consistência ajustável no Milvus é de facto semelhante às leituras seguidoras na replicação baseada no consenso. A funcionalidade de leitura de seguidores refere-se à utilização de réplicas de seguidores para efetuar tarefas de leitura de dados sob a premissa de uma forte consistência. O objetivo é aumentar o rendimento do cluster e reduzir a carga no líder. O mecanismo subjacente à função de leitura do seguidor consiste em inquirir o índice de confirmação do registo mais recente e fornecer o serviço de consulta até que todos os dados do índice de confirmação sejam aplicados às máquinas de estado.

No entanto, a conceção do Milvus não adoptou a estratégia de leitura seguidora. Por outras palavras, o Milvus não consulta o índice de confirmação sempre que recebe um pedido de consulta. Em vez disso, o Milvus adopta um mecanismo como a marca de água no Flink, que notifica o nó de consulta da localização do índice de confirmação num intervalo regular. A razão para este mecanismo é que os utilizadores do Milvus normalmente não exigem muito da consistência dos dados e podem aceitar um compromisso na visibilidade dos dados para melhorar o desempenho do sistema.

Além disso, o Milvus também adopta vários microsserviços e separa o armazenamento da computação. Na arquitetura Milvus, o S3, o MinIo e o Azure Blob são utilizados para armazenamento.

Milvus architecture Arquitetura Milvus

Resumo

Atualmente, um número crescente de bases de dados nativas da nuvem está a tornar a replicação de registos um serviço individual. Ao fazê-lo, o custo de adicionar réplicas só de leitura e replicação heterogénea pode ser reduzido. A utilização de vários microsserviços permite a rápida utilização de infra-estruturas maduras baseadas na nuvem, o que é impossível para as bases de dados tradicionais. Um serviço de registo individual pode confiar na replicação baseada no consenso, mas também pode seguir a estratégia da boneca russa para adotar vários protocolos de consistência em conjunto com o Paxos ou o Raft para alcançar a linearização.

Referências

  • Lamport L. Paxos tornado simples[J]. ACM SIGACT News (Coluna de Computação Distribuída) 32, 4 (Número inteiro 121, dezembro de 2001), 2001: 51-58.
  • Ongaro D, Ousterhout J. Em busca de um algoritmo de consenso compreensível[C]//2014 Conferência Técnica Anual da USENIX (Usenix ATC 14). 2014: 305-319.
  • Oki B M, Liskov B H. Replicação com carimbo de vista: A new primary copy method to support highly-available distributed systems[C]//Proceedings of the seventh annual ACM Symposium on Principles of distributed computing. 1988: 8-17.
  • Lin W, Yang M, Zhang L, et al. PacificA: Replicação em sistemas de armazenamento distribuído baseados em registos[J]. 2008.
  • Verbitski A, Gupta A, Saha D, et al. Amazon aurora: Sobre como evitar o consenso distribuído para i/os, commits e alterações de membros[C]//Proceedings of the 2018 International Conference on Management of Data. 2018: 789-796.
  • Antonopoulos P, Budovski A, Diaconu C, et al. Socrates: O novo servidor sql na nuvem[C]//Proceedings of the 2019 International Conference on Management of Data. 2019: 1743-1756.

Like the article? Spread the word

Continue Lendo