Em um artigo intitulado Megastore: Fornecer escalável, altamente disponível de armazenamento de Serviços Interativos (pdf) engenheiros do Google dar uma visão técnica.
A missão
Internet Suporte aplicativos como Google AppEngine.
Escala para milhões de usuários
Responsive apesar latências Internet para usuários impacientes
Fácil para os desenvolvedores
Falha de resiliência a partir de falhas na unidade de centro de perda de dados
Baixa latência de replicação síncrona para locais distantes
As principais premissas: 1) os dados para a maioria dos aplicativos pode ser dividida em entidades , por exemplo, pelo usuário, e 2) um subconjunto de recursos DB pode ajudar a produtividade do desenvolvedor.
Entidades
As entidades são sincronicamente replicado em uma área ampla. transações ACID dentro entidades são replicadas, mas não operações entre as entidades.
Para as operações inter-regional, a exigência de replicação síncrona está relaxado. fronteiras do grupo Entidade deve refletir o uso do aplicativo e as expectativas do usuário.
Por exemplo, uma conta de e-mail é uma entidade natural. Mas a definição de outras entidades é mais difícil.
Os dados geográficos, por exemplo, carece de granularidade natural. Então, o mundo é dividido em não-sobreposição entidades. Mudanças na utilização destas entidades geográficas (caro) commit de duas fases, enquanto as alterações realizadas por entidades não.
O truque: entidades suficientemente grande para fazer commit de duas fases incomum, mas pequena o suficiente para manter as taxas de transação baixo.
Disponibilidade e escala
Para atingir disponibilidade e escala global os estilistas implementadas duas principais características arquitetônicas:
Para disponibilidade, um replicador de log assíncrono otimizado para longa distância
Para a escala, os dados divididos em pequenos bancos de dados, cada um com seu próprio registro replicado
Replicação
O algoritmo Paxos venerável gerencia a replicação síncrona - com algumas otimizações Google desenvolveu:
Fast lê. atual leituras são normalmente a partir de réplicas locais mais uma vez escreve bem sucedido em todas as réplicas.
Fast escreve. Como a maioria dos aplicativos escrever repetidamente da mesma região, o escritor inicial é concedida prioridade para a réplica mais escreve. Usando réplicas locais e reduzindo a contenção de escrever distantes latência minimiza réplicas.
réplicas testemunha
. Testemunhas de votação nas rodadas Paxos e armazenar o write-ahead log, mas não armazenam dados de uma entidade ou índices de manter os custos reduzidos de armazenamento. Eles também são desempate quando quorum não é.
réplicas somente leitura
são o inverso: sem direito a voto réplicas que contêm fotos completa dos dados. Seus dados podem ser um pouco velho, mas eles ajudam a divulgar os dados sobre uma vasta área sem abrandar escreve.
Desempenho
Porque Megastore é geograficamente distribuídos, servidores de aplicação em diferentes locais podem iniciar escreve para o grupo de entidade simultaneamente. Só terá sucesso; outros escritores terão de repetir.
Para aplicações multiusuário, com mais escreve os desenvolvedores podem shard entidades mais fino ou operações de usuário em lote em poucas transações. Fine-grained bloqueios de aconselhamento e seqüenciamento de operações também ajudar a lidar com cargas de escrever.
O mundo real
Megastore foi implantado há vários anos em mais de 100 aplicativos de produção. Aqui está o que Megastore alcançou na produção:
Os bits de armazenamento tomar
Como Brewer teorema PAC mostrou, um sistema distribuído não pode fornecer consistência, disponibilidade e tolerância a partição para todos os nós ao mesmo tempo. Mas o Google mostra que as escolhas inteligentes podem nos levar darn perto.
Isso demonstra mais uma vez o valor do pensamento escala da Internet. fornecedores Enterprise nunca teria desenvolvido Megastore, mas agora que vi o trabalho que podemos começar a aplicar seus princípios a problemas de menor escala.
Nenhum comentário:
Postar um comentário